Keep Checkmk checks running when only notification hours should change

Bottom line: Choose notification-period rather than check-period restriction when the intended change is contact timing; stopping checks preserves the last state and can conceal a later failure.

Source fact: what the authority says

The Checkmk time-period guide says a host or service notification period prevents notification generation outside that period, before the notification-rule chain is evaluated. A check period stops check execution outside its active times and leaves the last status in place, including a potentially misleading earlier OK state. An individual notification rule can also have a time-period condition, for example to select a different notification method. A service period has a different role: defining the time population used for availability calculations.

What the source does not establish

This article selects among the documented time-period uses. It does not define an on-call calendar, establish current service health from an unchanged status or replace a separate maintenance-downtime decision.

Applicability questions

• Is the requirement to change contact hours, check execution or availability accounting?
• Which host or service population does the proposed rule cover?
• Should monitoring continue outside the contact window?
• Which separate notification rule or maintenance policy already applies?

DSE recommendation: controlled next steps

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

DSE recommends expressing the request as an operational outcome before selecting a time-period field. Ask the response owner whether observations must continue when nobody should be contacted. Keep check execution, notification generation, notification method and availability reporting as separate decisions in the rule review.

Draw the intended weekday and exception calendar beside the exact consuming rule. Review the boundary immediately before and after each relevant interval rather than checking only an ordinary daytime example. Obtain the calendar owner’s current exception list instead of copying a sample country’s holiday dates into production.

For a contact-hours change, preserve the observation requirement explicitly. Have the monitoring administrator compare the proposed notification setting with any existing check-period restriction. Resolve an unexplained restriction before relying on an unchanged displayed status as incident evidence, and avoid changing several time-dependent controls in the same trial.

Keep availability calculations under their own accepted reporting definition. Assign an owner to maintain the calendar and identify which rules consume it. Review a shared period’s other users before editing it for one service, and preserve the prior definition for the approved reversal.

Verification and evidence

Proposed verification: use a harmless test service and short approved test calendar. Compare actual check observations with notification behavior on both sides of the selected boundary, recording the rule and time used. If comparing a check-period restriction, keep it as a separately identified fixture with its own expected observation history.

Have a second operator trace the effective calendar through the specific consuming rule. Retain the state timestamps, notification observations and any exception-day result without claiming continuous health from one displayed value. Evaluate the availability report separately against its intended service-period definition before closing the calendar change.

Official references

• Checkmk — Time periods — 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.