Choose the Checkmk acknowledgment lifetime before marking a changing problem handled

Bottom line: Choose normal, sticky or explicitly time-limited acknowledgment from the intended status-change behavior; preserve the difference between acknowledgment and actual recovery.

Source fact: what the authority says

The Checkmk acknowledgment guide distinguishes a handled problem from an unhandled one; acknowledgment removes it from the Unhandled overview and suppresses further notifications. A normal acknowledgment ends on the next status change, whereas the sticky option retains it until the host or service reaches UP or OK. Commercial editions provide a timed expiry that deletes the acknowledgment at the specified deadline even without recovery. A persistent acknowledgment comment survives removal or expiry of the acknowledgment and needs separate manual deletion.

What the source does not establish

This article chooses acknowledgment lifetime and comment handling, not incident resolution or an alerting policy for every state. Timed expiry depends on the documented commercial-edition option; a handled label does not establish that the underlying fault was repaired.

Applicability questions

• Which host or service problem is being acknowledged, and who owns it?
• Should a later WARN-to-CRIT change reopen the operational task?
• Is the commercial timed-expiry option available and intended?
• Should the associated comment remain after the acknowledgment ends?

DSE recommendation: controlled next steps

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

DSE recommends writing the intended acknowledgment lifetime before applying the command. Name the responder and the next escalation checkpoint. Choose ordinary or sticky handling from that requirement rather than accepting whichever option was used for a previous incident. Keep actual service repair in the separate incident record.

Prepare a small state-transition table for an authorized harmless test service. Include the starting problem, a changed problem state and a return to normal. Mark whether the task should remain handled at each point, and have the response owner review that expectation before changing acknowledgment defaults.

Where a timed acknowledgment is appropriate and supported, choose its deadline from the actual handover or work window. Assign someone to review any unresolved problem when that time arrives. Avoid extending the acknowledgment repeatedly merely to reduce the unhandled count without a corresponding ownership decision.

Decide comment retention separately. Use a concise operational explanation without passwords or sensitive incident detail, and name the person responsible for later cleanup. Preserve the incident reference outside the comment so acknowledgment expiry and incident closure cannot be mistaken for the same administrative action.

Verification and evidence

Proposed verification: use the harmless test service to compare the approved ordinary and sticky cases through the written state sequence. Record the selected options, actual service states and acknowledgment observations. Compare the results with the response owner’s expectation without reporting the exercise as repair of a real fault.

If available and approved, exercise a separate timed-expiry case without forcing recovery. Inspect the acknowledgment and comment independently afterward, retaining actual timestamps and the chosen retention option. Have another responder explain which task is still unresolved and who owns it before adopting the reviewed defaults.

Official references

• Checkmk — Acknowledging problems — 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.