Taking Action: Acknowledge, Downtime & More

Prerequisites

Commands are submitted to your Nagios server's external command interface (cmd.cgi) — the same mechanism the web UI uses. That means your Nagios user needs command authorization on the server, configured in cgi.cfg. A user who can acknowledge from the web interface can acknowledge from NagMon; a read-only user (e.g. one listed in authorized_for_read_only) can't from either.

The relevant settings on the server side are the authorized_for_all_host_commands / authorized_for_all_service_commands directives (or contact-based authorization for the objects the user is a contact for). Our remote access guide discusses when a read-only account is the safer choice.

Acknowledging a problem

Acknowledging tells Nagios — and your teammates — "seen it, I'm on it." On any host or service that's in a problem state, the acknowledge action lives on the detail view.

• Comment — required, and can't be blank. Write something a colleague at 3 a.m. would find useful: "disk full on /var, cleaning up, ETA 20 min" beats "ack".
• Sticky — a sticky acknowledgement stays in effect until the object returns to OK/Up. Non-sticky acknowledgements are cleared if the problem changes state again (say, Warning worsens to Critical), so you get re-notified about the escalation.
• Notify — whether Nagios sends a notification to the other contacts announcing the acknowledgement.

Once acknowledged, Nagios stops sending repeat problem notifications for that object, and the acknowledgement is visible to everyone — in NagMon and in the web UI.

Scheduling downtime

Scheduled downtime is for planned work: patch windows, reboots, migrations. NagMon schedules fixed downtime — you pick a start and end time, add a comment, and during that window Nagios suppresses problem notifications for the object. When the window ends, normal alerting resumes automatically. No more "ignore the pager, that's just the reboot."

Other commands

• Recheck — ask Nagios to re-run the check immediately instead of waiting for the next scheduled run. The natural follow-up after you've fixed something: recheck, pull to refresh, watch it go green.
• Enable/disable notifications — toggle notifications for a specific host or service. Useful for a known-flaky check you plan to fix properly later; just remember these stay off until turned back on.

Multi-server note

With multiple servers enabled, commands always go to the server the host or service belongs to. You never have to think about routing — acknowledging web01 (PROD) in the merged view sends the command to PROD.

Verifying it worked

In the app, the object reflects the change after the next refresh — an acknowledged problem shows its acknowledgement, scheduled downtime appears on the object, a recheck updates the last-check time. On the server, every accepted command is written to nagios.log as an EXTERNAL COMMAND entry, so you (or your audit trail) can confirm exactly what was submitted and when:

grep 'EXTERNAL COMMAND' /usr/local/nagios/var/nagios.log | tail

If commands don't seem to arrive at all, it's almost always cgi.cfg authorization — see the troubleshooting checklist. (Also worth knowing: a command-submission bug affecting Digest-authenticated servers was fixed in NagMon 2.0.1 — make sure you're up to date.)