Acknowledging a problem in Checkmk marks a known DOWN, UNREACH, WARN, CRIT, or UNKNOWN state as handled while the affected host or service remains visible in monitoring. Use it when an operator has accepted ownership of an active alert and repeated notifications should stop while the issue is being worked.
Checkmk runs acknowledgments as commands against the affected host or service objects. The action can target one object from its detail page or selected rows from a problem view, and the available commands depend on the logged-in user's role and the object type being displayed.
A clear comment matters because it becomes the audit trail for the handled problem. Add the ticket, owner, or incident note before confirming the action, and use expiration or sticky behavior only when that matches how long the alert should stay handled.
Related: How to test Checkmk notification rules
Related: How to schedule Checkmk downtime
The detail view keeps the command scoped to that single object.
Running Acknowledge problems from a list without selected checkboxes can apply the command to every object currently shown in that view.

Include a ticket URL when available; Checkmk converts URLs in acknowledgment comments into clickable links.
Expire on is available in the commercial editions.
Without sticky handling, Checkmk can remove an acknowledgment when a problem changes state, such as from WARN to CRIT.
The acknowledged object can remain in a problem state, but it should no longer be counted as unhandled.