Alert lifecycle: triggered, acknowledged, resolved

Every alert in an on-call tool moves through a small set of states. It triggers, someone acknowledges it, and it resolves, with snooze, reassign and re-trigger along the way. The names differ between tools, and so do the details that matter at 03:00: whether acknowledging stops every notification, whether a resolved alert can come back, and who gets the alert when a snooze ends. This guide covers each state and transition, with how PagerDuty, Opsgenie, Grafana IRM and Prometheus Alertmanager handle them. For the basics of escalation, see what is alert escalation.

The states

State	What it means	Notifications	Escalation
Triggered	A problem was detected and nobody owns it yet	Sent to the current level	Runs
Acknowledged	A named person owns it and is working on it	Stop for that alert	Stops
Snoozed or silenced	Notifications are paused for a set time	Stop until the time ends	Paused
Resolved	The problem is over, or someone closed it	Stop. Some tools send a resolve notice	Ends

Alerts typically move from triggered to acknowledged, then to resolved. An alert might resolve directly from triggered. This occurs when the source reports the condition cleared before anyone acknowledged it.

What acknowledge does and does not mean

Acknowledging means "this is mine". In PagerDuty, the user who acknowledges claims ownership and halts the escalation process (PagerDuty, Incidents). In Opsgenie, acknowledging tells other responders the alert has been seen and is being worked on, prevents escalation, and makes the acknowledging user the alert's owner (Opsgenie, Acknowledge and unacknowledge). In Grafana IRM, it sets the status to Acknowledged and stops further escalation notifications (Grafana, Respond to alerts).

Acknowledging does not mean the problem is fixed, and it does not keep the alert quiet forever.

New occurrences are hidden. While a PagerDuty incident is acknowledged, it sends no more notifications, even if it receives new trigger events (PagerDuty, Send an alert event). In Grafana IRM, a new alert that joins an acknowledged alert group does not trigger escalation.
An acknowledgement can expire. PagerDuty's acknowledgement timeout, off by default, re-triggers an acknowledged incident after a set time and re-notifies the assigned responders, and the current on-call person if the rotation has moved on (PagerDuty, Configurable Service Settings). An Opsgenie escalation can be set to revert acknowledged and seen states on each repeat turn.
Acknowledge only what you were notified about. The PagerDuty incident response guide says not to acknowledge an incident out from under someone else; add a note with your findings instead (PagerDuty, Being On-Call).

A sensible default is to acknowledge as soon as you start working, so escalation stops, and resolve or hand over before you stop working. An acknowledged alert with nobody looking at it is worse than a triggered one, because the tool has stopped asking for help.

Resolve from the source or by hand

From the source. The monitoring tool sends a resolve when the condition clears. Prometheus alerts always include an end time, and Alertmanager sends resolved notifications when the receiver's send_resolved is true. That is the default for pagerduty_configs, opsgenie_configs and webhook_configs, and not for email_configs or slack_configs (Alertmanager configuration). With the PagerDuty Events API, a resolve event names the alert by its dedup_key, and must come through the same routing_key as the original trigger, or it is dropped.

By hand. Resolve manually when the source never sends resolves, or after you have confirmed the fix. PagerDuty can auto-resolve incidents after a set time, off by default, and recommends it for monitoring systems that send trigger events but not resolve events. It only applies to incidents created after you enable it (PagerDuty, Configurable Service Settings).

Let the source resolve alerts wherever it can. If you resolve by hand while the condition is still true, the alert comes back. With Alertmanager in front of PagerDuty, the next firing notification for that group, at the latest after repeat_interval (4 hours by default), arrives as a trigger for a resolved incident and opens a new one.

A resolved alert does not come back by itself. New events open a new one:

PagerDuty: a new trigger with the same dedup_key as a resolved incident opens a new incident. It does not reopen the old one. A person can reopen a resolved incident by hand if more work is needed (PagerDuty, Incidents).
Grafana IRM: a resolved alert group is closed to new alerts by default, so a matching alert creates a new group (Grafana, Alert groups).
Opsgenie: closed is final. The only remaining action is delete, and the alert's alias stops working (Opsgenie, Close and delete an alert).

Re-triggering and flapping

While an alert is open, repeated triggers attach to it. In PagerDuty, a trigger with the dedup_key of an open alert adds a trigger log entry to that alert instead of creating a new one. A trigger with no dedup_key always creates a new alert, because PagerDuty generates a unique key.

Flapping is an alert that resolves and triggers again and again. Each cycle is a new incident and a new notification. Prometheus has two settings that damp it (Prometheus, Alerting rules):

for keeps a new alert in the pending state until the condition has held for that long.
keep_firing_for keeps an alert firing for a set time after the condition was last met.

Opsgenie also has unacknowledge. It returns the alert to open and not acknowledged, and the tool behaves as if the alert was just created: notifications and escalations start again from the beginning. See alert deduplication and grouping for keeping repeats in one alert.

Snooze and silence

Tool	Name	Rules
PagerDuty	Snooze	Acknowledged incidents only. 1, 4, 8 or 24 hours, or a custom time up to 168 hours. When it ends, the incident returns to triggered and notifies again. If a different user has come on call since it triggered, both users are notified. Reassigning cancels the snooze.
Opsgenie	Snooze	Standard and Enterprise plans. Up to one week. Stops notifications and escalation. When it ends, the alert is open again and treated as just received, so whoever is on call then is notified. A snoozed acknowledged alert comes back open and not acknowledged. Acknowledging or closing cancels the snooze.
Grafana IRM	Silence	Keeps the alert group open and records signals from the source. When it ends, the group resolves if the source last reported resolved; otherwise escalation restarts. No notification is sent when the silence ends.
Alertmanager	Silence	Mutes alerts that match a set of matchers for a given time, before they reach any receiver.

Sources: PagerDuty, Edit Incidents, Opsgenie, Snooze an alert, Grafana, Respond to alerts, Alertmanager overview.

Use snooze for an alert you already own. Use silence at the source for planned work. Grafana notes that silences in IRM are independent of Alertmanager silences: silencing an alert group in IRM does not create a silence in Alertmanager. See silences and maintenance windows.

Reassign and escalate by hand

The notified engineer might not be able to handle the alert.

PagerDuty lets you move an incident to a different escalation level, a different escalation policy, or a specific user. Moving the incident to a level or policy keeps the policy cycling until someone acknowledges it. Moving it to a user notifies only that person and stops using the escalation policy. You cannot reassign low-urgency incidents to a level (PagerDuty, Reassign Incidents).
Grafana IRM allows you to add participants, which triggers their notification rules, or skip to the next escalation step. Skipping an acknowledged or silenced group clears that state and resumes escalation.

Hand alerts to a level or a policy instead of a named person. This keeps the escalation policy as a safety net. Record who you handed the alert to in the alert's notes.

How tools name the states

Concept	PagerDuty	Opsgenie	Grafana IRM	Alertmanager
New, unowned	Triggered	Open, not acknowledged	Firing	Firing
Owned	Acknowledged	Open, acknowledged	Acknowledged	No equivalent
Paused	Snoozed (acknowledged incidents only)	Snoozed	Silenced	Silenced (alert state `suppressed`)
Over	Resolved	Closed	Resolved	Resolved

Opsgenie tracks status as open or closed. It stores acknowledged and snoozed as separate boolean fields (Opsgenie, Alert API). Alertmanager assigns each alert a state of unprocessed, active or suppressed. Its notifications carry a status of firing or resolved (Alertmanager API spec). Before an alert reaches Alertmanager, a Prometheus rule is inactive, pending or firing.

Alertmanager has no acknowledge step. That step lives in the on-call tool it sends to. PagerDuty draws a similar line inside one tool. Alerts can only be triggered or resolved. Incidents are acknowledged. When all alerts in an incident resolve, the incident resolves. See Alertmanager routing.