ACK is short for acknowledged, and in PagerDuty it means a specific thing: a human has claimed ownership of the incident and the escalation process has stopped. Notifications stop going out. The incident does not escalate to the next person in the rotation. Nothing has been fixed, nothing has been diagnosed, and the outage clock is still running. Acknowledging is a statement about who is handling the problem, not about the problem.
This article covers the three incident states and what each one stops, the acknowledgement timeout that catches teams out in both directions, the difference between acknowledging and snoozing, and the cultural failure mode that the whole mechanism is designed to prevent.
The three states and what each one halts
PagerDuty incidents exist in one of three states. Triggered means the incident is open and unclaimed, and PagerDuty is working down the escalation policy notifying people until somebody responds. Acknowledged means a responder has taken it. Resolved means the underlying problem is fixed.
The distinction that matters is what each state stops. Acknowledging halts the escalation process and suspends notifications while the incident is acknowledged, which is exactly what you want when you have started work: it prevents PagerDuty from waking your backup and then your manager while you are already looking at the problem. Resolving stops everything permanently and closes the record. Neither has any effect on the outage itself, and acknowledging in particular is often mistaken by people watching a dashboard for progress. An incident sitting in acknowledged for forty minutes tells you somebody claimed it forty minutes ago and nothing else.
Unacknowledging exists for the case where you claimed something you cannot handle. It returns the incident to triggered, restarts the escalation process, and resumes notifications, which is the correct move when you realise the incident belongs to a different team.
The acknowledgement timeout
PagerDuty has a service-level setting that re-triggers acknowledged incidents after a configured period. When it fires, the incident returns to triggered, notifications resume to the assigned responder and, if the on-call rotation has changed in the meantime, to whoever is on call now. It exists to catch the incident that was acknowledged and then forgotten.
Two details about it cause confusion, and they pull in opposite directions. PagerDuty's own configuration documentation states that the acknowledgement timeout is turned off by default, which means many teams assume they have a safety net that is not actually enabled. Meanwhile a great deal of community guidance refers to a thirty minute default, and plenty of responders have been re-notified about an incident they acknowledged and concluded that acknowledging is broken. Both experiences are real because the setting is configured per service, and different services in the same account can behave differently.
The resolution is to look rather than assume. The setting lives on the service, under settings, in the assign and notify section, as a checkbox for re-triggering acknowledged incidents after a chosen period. Check what it says for the services that page you, because the answer determines whether an acknowledged incident is genuinely protected from escalation or merely postponed. Note separately that the escalation timeout, which defaults to thirty minutes, is a different setting entirely: it governs how long PagerDuty waits for an acknowledgement before escalating, not what happens after one.
Acknowledge, snooze, resolve
Three actions that look adjacent do quite different things. Acknowledging claims the incident and stops escalation. Snoozing applies to an already-acknowledged incident and temporarily suppresses re-notification, which is the honest tool for the situation where you know about the problem, cannot act for an hour, and do not want the acknowledgement timeout re-triggering it in the meantime. Resolving declares the problem fixed.
The mistake worth naming is resolving to make the noise stop. An incident resolved without being fixed removes the alert, closes the record, and guarantees the same alert fires again later with no memory of the first one. It also corrupts every metric derived from incident data, because a resolution timestamp is supposed to mean something. If the problem is that the alert is too noisy, the fix is in the alerting rules rather than in the resolve button, and our guide to incident triage covers how to sort real incidents from noise before they reach anyone's phone.
The failure mode all of this exists to prevent
The reason acknowledgement timeouts exist at all is a specific human behaviour: acknowledging an alert while half asleep and going back to bed. The mechanics make it easy, because acknowledging takes one tap and immediately stops the phone from making noise, which is the outcome the tired brain is optimising for. The incident is now claimed, escalation is halted, and nobody else will be notified, which means a total outage can sit acknowledged and untouched until morning with every automated safeguard working exactly as designed.
Guarding against this is partly configuration and partly culture. On the configuration side, enable the acknowledgement timeout on services where an unattended incident would be serious, and set it to something shorter than the time in which the outage becomes expensive. On the cultural side, teams that treat acknowledged as a state with a deadline rather than as a resting place tend not to have this problem. Some make it explicit, expecting a status note within a few minutes of any acknowledgement, which sounds bureaucratic until the first time it catches an incident that would otherwise have run overnight.
Odown integrates directly with PagerDuty, so an uptime or SSL failure arrives as a real incident inside the escalation policy you already run, rather than as an email somebody may or may not see.
Common mistakes in using acknowledgement
Reading acknowledged as handled. It means somebody claimed the incident, not that anyone has diagnosed or fixed it. An incident sitting acknowledged for an hour may represent an hour of work or an hour of nothing.
Assuming the acknowledgement timeout is on. PagerDuty's documentation states it is off by default and it is configured per service. Check the services that page you rather than assuming a safety net exists.
Resolving instead of acknowledging to stop notifications. Resolving closes the record and declares the problem fixed. The alert returns later with no connection to the first one, and every incident metric becomes unreliable.
Acknowledging without a plan to act. The one-tap acknowledgement at three in the morning stops escalation and stops anyone else from being told. That is a safeguard removed, not a task completed.
Confusing the escalation timeout with the acknowledgement timeout. The first controls how long PagerDuty waits for someone to acknowledge before escalating. The second controls what happens to an incident after it has been acknowledged.
FAQ
What is the difference between acknowledging and resolving in PagerDuty?
Acknowledging claims ownership and halts escalation and notifications while you work. Resolving declares the underlying problem fixed and closes the incident. Acknowledging changes who is responsible; resolving changes the state of the world.
Does acknowledging an incident stop it from escalating?
Yes, while it remains acknowledged. If the service has an acknowledgement timeout enabled, the incident re-triggers after that period and escalation resumes, including to whoever is on call at that later time.
Why did I get notified again about an incident I already acknowledged?
The service almost certainly has an acknowledgement timeout enabled, which re-triggers acknowledged incidents after a set period so they cannot be forgotten. The setting lives on the service under assign and notify.
What does snooze do that acknowledge does not?
Snooze temporarily suppresses re-notification on an incident that is already acknowledged, which is useful when you know about a problem but cannot act for a while. Acknowledge claims the incident; snooze buys quiet time on one you have already claimed.
Closing thought
Acknowledged is the most misread word on an incident dashboard, because it looks like progress and means possession. Everything the state does is about routing: it stops the pager, stops the escalation, and tells the rest of the organisation who to ask. None of it touches the outage, and a team that reads a wall of acknowledged incidents as a wall of handled ones has lost the thread of what the tool is telling them.
The other half of the problem is what reaches the escalation policy in the first place. Odown monitors uptime, API endpoints, and SSL certificates from seventeen locations and routes failures straight into PagerDuty, Opsgenie, Slack, Microsoft Teams, or a webhook, so real incidents arrive as incidents and noise never becomes something somebody has to acknowledge at three in the morning. Plans start at twelve dollars a month with a fourteen day trial and no card required.
