Ideas for Checkmk as submitted to our Feature Upvote board. Ideas are ordered by 'new' and the 50 top matches are included. pr_jkexfcbuunesmzd 2025-11-05T15:32:45Z sug_guodbwvytnkrud8 2026-06-01T13:22:58Z 2026-06-10T10:49:42Z The global setting “Use new service names” currently lacks transparency and makes it difficult to understand its impact. For each listed check plugin, it is not visible: - what the old service name was - what the new service name will be - whether there is a related Werk or documented change This makes it hard to assess the impact before enabling the option, especially in environments with: - existing rules based on service descriptions - integrations with external systems - reliance on historical data Suggested improvement: - Show old → new service name mapping per plugin - Provide a reference to the related Werk / documentation - Optionally include a short preview/example This would greatly improve usability and reduce the risk of unintended side effects. regards Christian sug_0bxpxdamrxtz3lx 2026-06-08T23:21:04Z 2026-06-10T05:49:11Z MSSQL Bakery rules don`t support the usage of domain credentials. Plugin supports that using a custom configuration file. sug_lzwnyrisx5pm9gw 2026-06-04T10:49:50Z 2026-06-08T07:25:04Z it would be nice to be able to use use the new Relay as a Gateway like system that is able to forward automatic Agent updates for Agents and eg. Webchecks inside a remote Network to limit Firewall roles for the Network in General. To be able to use it as a light weight distributed monitoring alternativ. sug_ll4iadn2nl4ybew 2026-06-01T05:27:09Z 2026-06-05T09:51:00Z In some cases, it is necessary to convert a regular Service Monitoring Rule into an Enforced Services Rule, or the other way around. This becomes especially cumbersome when dealing with a large number of services, as each rule has to be recreated manually. It would be very helpful to have a built-in option to convert or duplicate these rule types. Even if not all fields can be perfectly mapped (since some parameters may not exist in both rule types), having an initial conversion that pre-populates as much as possible would already save a significant amount of time. As an administrator, it is perfectly acceptable to manually adjust a few remaining fields afterward. The key goal is to reduce the repetitive effort required for recreating rules from scratch. Josef :) sug_jqgqmuvcmcmcmha 2026-06-01T11:19:51Z 2026-06-12T11:53:45Z There's a check for PoE consumption on switches, but it only has WARN and CRITICAL *upper* limits. We have had several occurences where the PoE part of a switch died and the rest of the switch kept working perfectly fine. PoE consumption was still reported by the switch but went to 0 - for which there's no WARN or CRITICAL. So it would be useful to have threshold settings / rules for the PoE consumption check to warn me when it's at a too low of a realistic level. sug_mtrmskmttshdwef 2026-05-28T10:45:23Z 2026-06-01T14:40:31Z HAProxy checks currently expose only the session rate metric. The agent output already contains additional metrics, so it would be great to expose more of them. Please add session-related metrics. sug_etoeiqqj0evjuko 2026-04-24T19:14:13Z 2026-05-28T14:16:24Z separate sitenames from usernames; allow site to run under generic usernames, do not mandate username to match sitename. this will allow more flexible deployment and management. this is more relevant in area where usernames are centrally managed and access to external resources are all tied to usernames and credentials. sug_uzib0d1rfonmlrp 2026-04-22T11:37:57Z 2026-05-28T14:10:05Z During Checkmk backend updates (e.g. stopping a site), users are frequently confronted with red error messages such as “Unhandled exception”. This creates the impression that Checkmk is broken, even though the behavior is expected during maintenance activities. Key issues: - The wording “Unhandled exception” is misleading and alarming for end users. - Similar messages appear in multiple places and give poor UX signals during planned maintenance, but also in general. - Existing downtime/maintenance mechanisms do not seem to cover backend or site-level maintenance properly. Suggested improvement: Introduce clearer, maintenance-aware status messages when a site or backend is intentionally stopped. Replace generic technical error messages with user-friendly explanations (e.g. “System is currently under maintenance”). Ideally provide a dedicated maintenance mode for Checkmk itself, not only for monitored hosts/services. This would significantly reduce confusion, false incident reports, and improve overall user experience during upgrades and maintenance windows. sug_w0nmnuhyehfaxwo 2026-05-08T09:21:28Z 2026-05-28T14:06:14Z At the moment it is not possible to configure how many backups should be kept. That would be a nice feature. At the moment we need to run a cronjob that delets old backups. Also a cool feature would be adding the date/time of the backup in the foldername. Another point is, if you export backup keys, the descrition is not used. So if you have more than one there alre names "key-1", "key-2". You have to rename it afterwards. If you would add the "description" to the filename that would be nice sug_iagc8bg3twt2xaw 2026-05-22T10:09:31Z 2026-05-28T11:27:54Z Add a function to temporarily show or hide columns in the current view (similar to adding/removing filters in filter menu), without having to edit the view each time. Sometimes I need to adjust the columns shown because certain information is missing or to hide columns that are not relevant and take up too much screen space, which results in unnecessary horizontal scrolling. Example: I am running a Quicksearch for all services starting with HTTP because I need to know which check is used for each service (e.g., custom, check_http, check_httpv2, etc.). In this case, the Summary, Perf-O-Meter, and some other columns are not relevant. However, I would like to display the Check command column, which is normally not shown in this view. This feature enables a faster and more focused view, especially when certain information is not relevant in the given context and occupies unnecessary space in the current view. sug_jlfw8o8gs0qktx3 2026-05-25T07:22:39Z 2026-05-27T10:04:49Z Reproduce in Checkmk Raw Edition 2.5.0-2025.11.04: Search: "Check_MK Agent" Search result of service and label e.g. "Local site cmk fedora-dev-host-212" are not in the same grey box. User assumes box combines label and service, but the current style combines the service and the label of next line. Also sort on "Summary" would be nice to quickly see if hosts run outdated agents. sug_fvrjwhmxsnvcp8a 2026-05-22T07:14:30Z 2026-05-26T07:14:20Z Hello Checkmk Team and Checkmk Community, some Versions ago (i'm not sure if it was during 1.X or still exists in 2.X) it was possible to edit the ID of a BI Pack/Rule/Aggregation directly in the rule. Since somwhen it is not possible anymore. So if i made a mistake in a Pack/Rule/Aggregation i need to re-create (in case of Packs create a new pack and move rules, else just copying) the ID i want to change. It would be nice if there would be an option to edit the ID again. Like on "older" Versions, in this case no other modification can be done in the same step. The most advantage would be to safe a lot of time if you don't have to copy everything - and adjust "Call a Rule" entries. For example it took me ~1h for 6 Packs to recreate Packs/Rules/Aggregation and re-linking the "Call a Rule", and this was a quite simple straight forward doing. i can imagine, in a more complex environment with a lot of "Call a Rule"s, it may take much longer. As mentioned, this already existed in older Versions. But since some time the ID is fixed after the first creation. Greetings Andreas sug_n6ywmfykscyqs1f 2026-05-20T11:15:51Z 2026-05-25T09:51:45Z When using subreports to include hosts in a parent report (e.g. "Switch details" subreport called from a template-based bundle), the hosts are currently returned in creation order — the order they were added to CheckMK — with no documented global setting or per-subreport override to change this behavior. This creates a poor end-user experience in customer-facing PDF reports, where hosts appear in an arbitrary, non-alphabetical sequence. Since the parent report cannot impose sort settings on child/subreport elements, and the subreport itself currently offers no persistent sort configuration, there is no supported way to produce a consistently ordered host list across report runs. An improvement would be to allow sort order to be configured for host elements within subreports — ideally supporting at minimum alphabetical (ascending/descending) sorting by hostname (or at least changing the default behaviour to this) — with the setting persisting as part of the subreport definition. Alternatively, allow the parent report to pass or override the sort order for included subreport elements. This affects any MSP or enterprise user generating automated, customer-facing reports via the Reporting module. Unpredictable host ordering in delivered PDF reports looks unprofessional and undermines confidence in the monitoring platform. sug_xewgvteubjqkdfn 2026-05-21T16:12:06Z 2026-05-25T07:30:45Z To make the use of HTML in check output safer and more controlled, the existing Escape HTML rule should be extended with an additional option called Sanitize HTML. Rendering modes: * Escape HTML: escaped plain text (existing) * Don't esacpe HTML: unescaped raw HTML (existing) * Sanitized HTML: sanitized HTML rendering (new) When the Sanitized HTML option is selected, the returned HTML code will be cleaned before display using a sanitizer such as DOMPurify or nh3, removing untrusted or potentially harmful content in accordance with best practices. This enhancement allows users to control how HTML content in the output is displayed, as plain text, basic HTML, or sanitized HTML, providing greater flexibility while maintaining security and stability across all components. Since this functionality operates between the checks and the GUI, it can be used uniformly for all checks without requiring any modifications to the checks themselves. sug_q5utmrdcvepv01u 2026-05-21T17:33:52Z 2026-05-22T16:05:39Z In many situations, it would be helpful to view the exact content displayed on the website when a check fails (similar to the --show-body option in check_http). Often, the returned page contains valuable information that can significantly support troubleshooting. For example, when the search string does not match or when an API returns an HTTP code other than 200, it would be beneficial to view the corresponding response content. I propose adding a configuration option that allows users to choose between the following modes: * Never – never show content * On Error – show content only when the check fails * Always – always show the returned content I understand that the displayed content may pose certain risks. However, the decision on whether this risk is acceptable should be left to me and not be restricted by default. An additional option "show simple HTML" that determines whether potentially harmful elements are removed or raw data is displayed could make the display both safer and more flexible. To address this potential issue more generally, please also refer to this suggestion about adding a sanitize HTML option for safer check output rendering: https://ideas.checkmk.com/suggestions/713053/add-sanitize-html-option-for-safer-check-output-rendering Since the error that triggered the alert often cannot be reproduced afterwards, this feature would significantly enhance the diagnostic capabilities for websites and HTTP-based APIs. sug_zani2ldfs9nilu5 2026-05-21T08:55:37Z 2026-05-22T16:02:35Z Cato Networks SD-WAN Monitoring needed to CheckMK, Cato has good status page https://status.catonetworks.com/ but for networ monitoring needed to own infra monitoring, incidents and issues from certain pops and customizable pops monitored, no need to be global. GraphQL API reference exists https://api.catonetworks.com/documentation/#introduction sug_vofwr1s4ylicfbm 2026-05-21T08:45:36Z 2026-06-01T14:46:09Z The current text is really verbose and when many of them are shown on the same page it’s really hard to read them E.g. "Cache generated 9 hours 53 minutes ago, cache interval: 1 day 0 hours, elapsed cache lifespan: 41.24%" It would be nice if it were shortened by also removing esoteric or zero-valued info. E.g. something similar to this: "Cached 9h 53m ago (update interval: 1d)" sug_xqzjuxagaoeqwug 2026-05-20T15:15:30Z 2026-05-22T15:53:06Z With the native Windows Task plugin in Checkmk, it is currently only possible to monitor all tasks, except for excluding the default Microsoft folder. It would be very helpful if it were possible to monitor only a specific folder instead. This way, tasks in the root folder would not be included, which is important because many automatically created Microsoft tasks reside there and usually do not require monitoring. Using rules to disable unwanted tasks is not an ideal solution, especially in larger environments with more than 10,000 hosts. This approach would result in a large number of disabled services, making the monitoring configuration harder to manage and less transparent. A possible solution could be to introduce an inclusion-based filtering mechanism (maybe by folder path or regex), allowing administrators to explicitly define which task folders should be monitored. This would greatly improve scalability, reduce noise, and simplify rule management in large environments. sug_6p7mk5q2thgjcrq 2026-05-18T06:25:03Z 2026-05-22T15:52:18Z At the moment there's only an option to set "State for connection refusal". Add an option for "State for connection established". That's sometimes very userfull if you want to check if an TCP port is NOT open. sug_r8gq13ad2vbadzt 2026-05-18T08:22:55Z 2026-05-20T14:16:50Z At the moment it's not posible to configure timing parameters for windows tasks. It would be nice if you could configure things like "task has to run every X hours/days". So that it's ok if the task failes once but next time the task runs without failure. sug_micubpc95oejxb4 2026-05-11T09:07:10Z 2026-05-19T14:43:44Z We have a weekly maintenance window for our hosts on Wednesday at 18:00. We currently use scheduled downtimes on services that receive a non-critical alert. This means we get the alert when an event occurs, but postpone those that don't need immediate action to the maintenance window. Works really well for us. But it's a nuisance to schedule the downtime, as I need to use the datepicker and manually edit the time. Downtime presets are very limited in that they only allow next next day/week/month/year. Would it be possible to add the possibility to add downtime presets such as "next Wednesday at 18:00"? sug_cstnt9usnyyfycy 2026-05-05T06:02:19Z 2026-05-13T12:39:43Z There are a few holidays that happen on the same date every year. Would it be possible to let us specify the year as 0000 when an exception happens on the same date every year? I.e. 0000-12-24. I suggest 0000 because the year 0 is a non existing year. The years go from 1 bc directly to 1 ad. sug_zbyfwxwy0ov4pzn 2026-05-12T13:23:13Z 2026-05-13T12:38:43Z There are many variables that can be included in notifications, but ‘Custom host notes’ is not one of them. Please add this variable to the list. It would also be useful if this variable could be enabled directly within the WATO GUI for notification rules. sug_bwikkwns4ggkphl 2026-04-28T14:00:03Z 2026-05-06T08:52:53Z Hi all, based on our recent problem, it is currently quite easy for owners and users of k8s to quickly fill up nearly any space on checkmk /omd filesystem by just quickly deploying and killing again objects in k8s. Autoscaling, autopilot GKE cluster can easily start and kill nodes, pods and other objects in massive numbers. DCD thus constantly creates new hosts and removes inactive ones from config. The catch is that RRDs that are created for each remain in place after the DCD removes the host. This leads to /omd filling rapidly on the site with no longer active hosts. Rapidly meaning a constant growth 80GB space/day or more. This way, k8s or anything else of the kind, like podman, docker, VMware etc could basically DoS the site just by running such workload. Because of that, the ordinary disk cleanup will not do - it works with days at least and it is not possible to tell it "remove only RRD's of hosts based on this label/pattern that had not been written to for more than X hours or Y days". Proposal is threefold: 1 - DCD could have an option for removing RRD's (and perhaps the inventory) of the host as well on host removal or after configurable delay. Perhaps even optionally based on the regex of the hostname, that would really help. 2 - It would be great to have in DCD the possibility to hint a renaming scheme of object like pod to provide constant naming. Like, deployment having always pod_deployment_a_1 to pod_deployment_a_X pods in it, regardles off true object names. Either by plugin, or by calling user-provided code to do a "standardisation". 3 - diskspace cleanup could have again an option to configure patterns for hosts with different "retention periods", not just a single period for everything on the site. So far, I was forced to whip up a bit dirty script to cleanup specific ballast that tends to accumulate and cause problems, but it is still working from the crontab and cannot help with filesystem filling in less than two days. sug_jx2qo9aka4bcpdv 2026-04-23T09:31:02Z 2026-05-08T08:25:43Z Only Pure Flasharrays can be monitored, integration of Pure Flashblades would be great sug_fnjelro0smj0ept 2026-04-22T22:25:48Z 2026-05-04T15:24:25Z When monitoring SUSE Virtualization nodes via SSH using a shell-based Checkmk agent script, service discovery produces an unmanageable number of irrelevant services: ephemeral container overlay mounts, KubeVirt internal devices, transient filesystems, and similar artifacts inherent to the platform. Some of these default to CRITICAL, requiring significant manual effort to reach a clean and meaningful monitoring baseline. This problem is compounded by the fact that SUSE Virtualization runs on SLE Micro, an immutable operating system using transactional updates and snapshot-based rollbacks. Any manual configuration applied to the node can be lost after an OS update, forcing administrators to repeat the cleanup process from scratch. The result is a lack of stable monitoring baselines, persistent false alerts, and ongoing operational overhead with every update cycle. Proposed solution: an official SUSE Virtualization Node Monitoring Profile shipped with Checkmk, defining: - Which mountpoints and devices to exclude by default on SLE Micro based nodes - Meaningful default thresholds appropriate for SUSE Virtualization workloads - A curated service discovery ruleset that produces a clean baseline on any fresh node Developing this profile requires collaboration with SUSE to define what a healthy SUSE Virtualization node looks like from a monitoring perspective. We have established relationships on the SUSE side and are confident the right people can be brought to the table should Checkmk be interested in pursuing this. Who benefits: any organization running Checkmk on SUSE Virtualization nodes. sug_qwrugujj5sckjfs 2026-04-22T16:21:58Z 2026-05-04T15:21:15Z Add the possibility to configure an execution interval together with simple time windows during which custom queries are allowed to run - for example, every 30 minutes between 08:00 and 17:00 from Monday to Friday, or once daily at 08:00. When the current time falls outside the defined window, instead of executing the custom query, mk-oracle could return a standardized message such as: “Skipping execution: outside check period.” Benefits: * Increased flexibility in query scheduling. * More efficient use of resources by limiting checks to relevant time periods. * Transparent and predictable query behaviour through clear feedback when executions are skipped intentionally. Example Yaml configuration: Schedule: Mon: - "0800-1100" - "1300-1700" Tue: - "0900-1100" Wed: - "0900-1100" - "1300-1700" Sat: - "0800-0805" sug_qpwqnfyzaft2hcg 2026-04-22T16:05:46Z 2026-05-04T15:20:09Z Use regular expressions in both the include and exclude for discovered CDBs, and extend this capability to allow regex‑based inclusion and exclusion of PDBs detected within those CDBs. This enhancement makes the discovery process more flexible and reduces manual configuration effort by enabling dynamic filtering of instances and databases based on naming patterns. sug_2k6zqoyvctxvqtb 2026-04-20T13:04:14Z 2026-04-28T15:48:53Z REST API: Please return the ID for each rule implemented via the API to ensure that further processing always takes place (Delete, tracing, logging, etc.) Showing all rules and searching by text for the ID is no solution at all in 2026. (Downtimes, Notifications, etc. in general at all rules we add) sug_5r6p597iv239xoi 2026-04-16T12:17:18Z 2026-04-20T19:18:55Z Allow agent to send data to a failover destination when the original destination is not reachable. The idea is to be able to easily switch the monitoring destination without having to redeploy agent configurations. If a disaster happens at the original IP which makes it not reachable we could easily restore the site backup in the secondary site (failover) and have everything working. Agents will try to connect to the original IP and then after failure will send the data to the secondary one. sug_cq41i47fdgrleex 2026-04-19T07:25:26Z 2026-04-20T14:47:24Z Requesting a custom agent for XCP-ng and Xen Orchestra. Looking to monitor VMs, cluster performance and host performance. Similar to the VMware and Vcenter custom plug-ins sug_6fu10ihgqiyoycc 2026-04-17T10:06:41Z 2026-04-20T14:47:06Z The current check-httpv2 requires that the certificate be validated against a RootCA on the local server for certificate monitoring. However, this makes absolutely no sense, especially when monitoring many customer systems, each with their own PKIs (and thus also custom RootCAs). We would like to check the certificate age, but WITHOUT validating it against a RootCA. I don’t want to have to import all customer Root CA certificates into my CheckMK server just to check the validity period. As things stand now, if I were to monitor an SSL certificate from a customer that was issued by their own PKI (i.e., not by a public RootCA), I would first have to import that RootCA into the CheckMK server—and that is exactly what I don't want to do. For this, I still have to use the external “check_http” (from Nagios, because here I can explicitly check only the validity period) and cannot use the new “Check HTTP web service”, because it simply expects you to trust the RootCA. Here, I expect an option to “check certificate validity period only” sug_du0fmomlua3fxj8 2026-04-15T14:39:41Z 2026-04-20T14:43:19Z https://forum.checkmk.com/t/redfish-plugin-missing-parameter-for-predictedmedialifeleftpercent-for-ssds/58009?u=stefanm sug_lrk8r1j5gmvyrxb 2026-04-14T10:19:08Z 2026-04-20T14:40:12Z Often we have to monitor a single host with a Web server that has different VirtualHosts and DNS names. The current certificate check does not provide any options to check certificates for different VirtualHosts of the same Webserver. Please add this option. The deprecated check has it. sug_3xohsqxms8opbgz 2026-04-09T09:59:54Z 2026-04-10T09:19:23Z Rules in Checkmk should be able to apply to a specific check type, such as check_mk_active-httpv2, rather than across all services with similar names. As an example, the Service Name of several HTTP-related checks starts with HTTP. In my use case, it would be highly useful to configure certain rules, such as “Escape HTML in service output,” exclusively for the check_mk_active-httpv2 check and set it to Don’t escape HTML. Achieving this today requires multiple separate rules with carefully defined name patterns, which is inefficient and error-prone. Introducing a direct way to identify and select specific check types would make rule configuration cleaner, more precise, and easier to maintain. Benefits: Simplifies rule management, reduces configuration complexity, and prevents unintended effects on unrelated checks. Possible solution: A service label such as "cmk/check_type:check_mk_active-httpv2" would be fully sufficient and integrate seamlessly into the existing label-based rule concept. sug_inrg03b0coqxhju 2026-04-09T14:45:10Z 2026-04-10T08:25:51Z Problem Statement: In Event Console when using the "send monitoring notification" action the overall Event Console (mkeventd) throughput decreases dramatically (to about 1,4 eps), since all events are processed sequentially and the "cmk --notify" action is being processed synchronously. In many cases, it is not necessary to wait for the result of a notification-handling action before processing the next event, especially when that next event may also trigger notifications. Allowing a certain level of concurrency in EC actions similar to how the notification subsystem mknotifyd already supports parallel processing would significantly improve throughput. Logwatch (log file monitoring) forwarding or SNMP monitoring would be typical use cases to benefit from this. Suggestion: By executing actions in the background asynchronously the Event Console could handle events much more efficiently (light weight). This would make it possible to reach substantially higher processing rates, on the order of 50–200 events per second. This concept is comparable to how the EC already supports asynchronous custom actions such as “Execute shell script.” However, these custom actions currently provide less context and require more manual work. Builtin support for asynchronous EC actions would therefore offer clearer structure, better context management, and much higher throughput figures than only 1,4 events per second. sug_4giftpfecoilprt 2026-04-09T14:51:36Z 2026-04-10T08:23:42Z Currently a Checkmk HA cluster is designed to compensate for hardware failures within a single datacenter or local network, not for geographic redundancy. We see the requirements of our internal customer and the regulators growing and we expect that in a few years we need a solution to offer the monitoring always-on and high available cross-datacenters Shortcomings we see in the current offering Checkmk is not designed to run an active passive cluster stretched across two or three datacenters. When the connection between two nodes goes down, the passive node assumes control and becomes active. Suppose these nodes are in different datacenters and there is a problem with the connectivity between those datacenters, there is no way for deciding which datacenter is the one that is still online and thus which node should assume the active role. This creates a risk of both nodes attempting to become active at the same time. The current design also requires both Checkmk servers to be located in the same network segment because the cluster depends on a shared cluster address. While we could technically stretch a network segment across datacenters, this is not always an option. The reason is that sharing the same segment creates a single dependency: a misconfiguration or corruption of that network segment can disrupt both servers. Another important limitation is that upgrades of a Checkmk cluster require a complete outage. High availability includes the expectation that planned maintenance does not cause downtime aka “always-on” With the current cluster model this is not achievable. Given the growing importance of uninterrupted monitoring, we would like to request that real high availability across datacenters, not dependent on appliances or stretched network segments, be considered for inclusion in the Checkmk roadmap. We fully recognise the complexity of this request, but we also believe sug_es5x6bgp16lyyup 2026-04-07T09:38:42Z 2026-04-09T11:13:59Z lib/nagios/plugins/check_cert --hostname checkmk.com -p 443 --not-after 1814400 1814400 invalid args (?) sug_uml2xrnrbrjlc3d 2026-03-26T16:49:11Z 2026-04-09T11:14:28Z when customising the location of (Linux) agent, the path a console looks to trigger a remote alert handler is not, also, customised. either within the agent setting or global settings, add parameter to specify path to remote alert handlers. alternatively, update the underlying code to automatically update the pathing, internally, when the agent is customised. sug_xvfoptrvfjvkxap 2026-03-25T17:33:09Z 2026-04-09T09:29:10Z Consider adding a standard plugin/check to add support to create service checks for PSI (pressure stall information) cpu, memory and io metrics on Linux hosts running kernel version 4.2.0 or higher. A user has posted a sample check as s custom plugin/script at https://github.com/hweidner/check-mk-goodies/blob/master/README.md#psi-pressure-stall-information See also: https://unixism.net/2019/08/linux-pressure-stall-information-psi-by-example/ https://www.youtube.com/watch?v=Mf5FrDFALW8&t=866s https://lwn.net/Articles/759781/ https://lwn.net/Articles/759658/ Rationale: PSI intends to expose metrics we can use to gauge whether processes are actually experiencing actual cpu, memory or io contention whereas cpu_utilization and cpu_load metrics only inform a general idea as to whether there are cpu utilization resource contention on the linux host at hand. This feature has existed in the linux kernel since 4.2.0 circa 2018. The links above give a good starter explanation. sug_5vjzbv9ee9bkxs5 2026-03-29T12:13:23Z 2026-04-09T09:26:26Z Instead of adding the NUT Package manually, could you please include this in an upcomming release of checkmk? This would enable everyone to monitor their NUT UPS or NUT Servers out of the box, instead of manually add something to the installation. Thanks a lot :) sug_xv4njbwqcurjuds 2026-04-03T12:02:47Z 2026-04-09T09:24:36Z The URL being checked in check_httpv2 should be displayed directly instead of being hidden behind an icon. The details section is clear structured, but concealing the URL behind an Icon makes it difficult to quickly identify which site is affected. The URL should always be visible, and when the “Follow the redirection” option is enabled, both the originally requested URL and the final reached endpoint should be shown. This would give alert recipients immediate clarity on what was checked and where the issue occurred, enabling faster and more accurate responses. https://forum.checkmk.com/t/make-url-display-in-check-httpv2-more-transparent-and-user-friendly/57933 sug_qtxt4p9u9g0yo76 2026-03-19T08:48:12Z 2026-04-02T10:15:03Z Hey, it would be useful to have a field/parameter that shows the execution time of each plugin (or show it within the "check_mk" Service). [agent] Success, [piggyback] Successfully processed from source 'XXXX', Successfully processed from source 'XXX', execution time 49.1 sec - PluginXY time: 10 sec Plugins or local scripts in particular can sometimes run much longer than expected. With such a field/parameter, you could easily see how long the individual plugins or scripts are taking to execute. At the moment, you have to remove the script, bake agents, check the agent execution time - and repeat this multiple times - until you finally identify the plugin or script causing the long runtime. Josef :) sug_weamgcg4lp5utah 2026-03-30T23:50:57Z 2026-04-02T10:07:10Z When creating the rules from Self-Registration and Agent Updater allow the retrieval of URLs from Distributed Monitoring page. This will allow the setup of those rules with few to zero fields written manually. sug_ywvs9muwuus2dvs 2026-03-23T15:32:55Z 2026-04-03T13:46:55Z Currently, only the X-axis supports both horizontal scrolling (click & drag) and zooming (mouse wheel) in graphs. Vertical click & drag typically rescales only the MAX value. This causes issues: With large ranges (e.g., 3 TB disk space), even significant changes (e.g., a sudden 10GB jump) appear minimal. It is not possible to zoom into a range like 2.9-3 TB using current interactions. Click & drag is commonly expected to pan/scroll, making the current behavior feel inconsistent. Workaround: Graph tunings exist, but they are not easily discoverable, require per-graph rules, and become outdated quickly. Suggestion: Use click & drag for panning by default and mouse wheel for zooming. Support Shift/Ctrl modifiers to constrain interactions to the X or Y axis. sug_ottkrgt0zde5txy 2026-03-26T16:01:49Z 2026-03-27T09:19:44Z I think it would be useful to be able to build a view or have a dashboard for users to be able to quick see the host and/or services that they have personally acknowledged. I can create views and dashboards with this in mind but there's no current way to filter or group by the acknowledged by field which is displayed with the comment field. sug_wfvuhzpbboqrr5j 2026-03-26T16:04:26Z 2026-03-27T09:18:41Z If a host is notified because of becoming DOWN, the event overview contains the following Summary: >Event overview >Event date: 2026-03-26 12:11:42 >Address: 1.2.3.4 >Site: sitename >Summary: No IP packet received for 60.592049 s (deadline is 60.000000 s) This is ok for directly sent notifications, but not if it was combined with a "Delay host notifications" rule as the user thinks the host is only DOWN for "60 seconds" although it is DOWN for "60 seconds + delay value". sug_vxoti6xhuvheb6o 2026-03-18T17:52:54Z 2026-03-25T15:08:25Z It would be nice if CheckMK supported SCIM provisioning. The login via SAML syncs at login time, which is nice, but about half of our users never log into CheckMK so I can't update their contact groups. sug_d7rzhwe1ya7uhgy 2026-03-20T14:31:52Z 2026-03-25T14:57:14Z Based on:SUP-28228 We need a solution for a fully functioning BI: Rule: Toggle Preview. So that we are able to verify all of our BI rules and its parameter as preview. sug_nonv0hyvvotzl3o 2026-03-10T17:19:51Z 2026-03-27T09:20:22Z Currently, the "Process Discovery" ruleset serves dual purposes: monitoring processes and auto-discovering server roles. While it is possible to use host labels for discovery purposes, this is not the main goal of the ruleset and represents a powerful capability that deserves dedicated support. Usually, the definition of server roles is done manually by using Host Tags, which might lead to errors and inconsistencies. A dedicated discovery ruleset would unlock the full potential of automated role detection—allowing organizations to build intelligent, self-configuring infrastructure that automatically adapts monitoring strategies based on what it discovers, rather than requiring manual classification. Example 1 - Oracle Database Server: Rule: IF (process "oracle*" is running) OR (folder "/u01/oradata" exists) THEN → Assign role "database" (generic) + "oracle_database" (specific) → Install "Oracle Monitoring" plugin