Review every matching Checkmk active-check rule before adding another

Bottom line: Review the full set of matching active-check rules and expected generated services instead of assuming ordinary first-match behavior or service-discovery acceptance.

Source fact: what the authority says

The Checkmk active-check guide evaluates every rule whose conditions match the host, rather than stopping at the first matching active-check rule. Active-check services are generated automatically instead of being incorporated through service discovery. Ordinary active checks run on the Checkmk server; MRPE is the documented exception that executes on a monitored host. Their execution is independent of passive services, and they can continue checking while the monitored host is DOWN.

What the source does not establish

This article reviews active-rule accumulation and observation location. It does not assume every rule supports the same target-default behavior, approve network probes or infer an application’s availability from one check result.

Applicability questions

• Which active-check rules match the intended host population?
• What service identity and endpoint does each matching rule intend to create?
• Where should the check actually execute?
• Which independent application observation is required beyond its monitoring result?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a rule-to-service inventory before adding another active check. List every applicable rule, condition, intended service description and endpoint. Have the service owner review the complete population instead of approving the first matching rule as the whole configuration.

Use distinct harmless service descriptions for the initial overlapping-rule fixture. Identify a host that should match one reviewed rule and another that should match both. Resolve unintended rule scope before changing endpoints or deleting a service merely because the resulting list differs from the expected inventory.

Record the intended execution location with each observation. Keep ordinary server-side checks distinct from an expressly selected MRPE design. Ask the network owner to approve the test route and the application owner to define a harmless request; a convenient result from another location should not replace that path requirement.

Review the actual rule’s target fields and inline documentation before relying on an omitted value. Preserve the prior rules and the chosen test population for reversal. Keep the generated-service review separate from application release acceptance and avoid treating service discovery as the only place to assess the active-check inventory.

Verification and evidence

Proposed verification: activate the reviewed rule fixture in an approved test scope and compare the resulting service inventory with the written one-rule and overlap cases. Record every effective condition, service identity and actual endpoint without assuming two rules with conflicting descriptions have a documented merge behavior.

Run the authorized harmless network observations from the intended execution context and compare actual results separately from service creation. Retain a missing or unexpected service as a configuration finding. Have the responsible owners reconcile rule scope and observation path before expanding the check population to production hosts.

Official references

• Checkmk — Monitoring network services (Active checks) — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.