Escalation Policies & Paging Chains

## Ack is a claim of ownership Every paging tool gives an incident three states that matter: triggered, acknowledged, resolved. Engineers new to on-call read "acknowledged" as a read receipt — the equivalent of marking an email seen. It is not. In an escalation policy, the acknowledgement is the signal that stops the machine from looking for anyone else. The correct mental model is: *I am awake, I have this, stop waking people.* ## What the ack does mechanically When an alert routes to a service, the escalation policy starts a timer on rung one. If the target acknowledges before the timeout, the chain halts — the secondary is never notified, the manager rung is never reached. If nobody acknowledges, the timeout expires and the page advances. So the ack is the off switch for redundancy. Pressing it is a promise that the redundancy is no longer needed, because a competent human is now on the problem. ## The ack-and-sleep failure The classic incident postmortem line is: "the page was acknowledged at 02:14; the first human action in the logs is at 03:40." What happened in between is almost always the same story — someone half-woke, hit acknowledge on their phone to make the noise stop, and fell back asleep. The result is strictly worse than not answering at all: - Had they not acked, the chain would have escalated to the secondary within minutes and someone would be working it. - Because they acked, the paging tool's dashboards say the incident is handled, so nobody escalating from another direction sees a problem either. This is why the operational rule is blunt: **do not acknowledge a page you are not about to work.** If you are unfit — too tired, in a car, mid-way through another incident — either let it escalate, or acknowledge and immediately reassign or manually escalate to the next person. A deliberate handoff is fine. A silent one is not. ## Acknowledgement timeouts and re-triggering Because the ack-and-sleep case is so common, most paging tools offer a second safety net: an acknowledgement timeout at the service level. If an incident has been acknowledged but not resolved after a configured period, the tool un-acknowledges it and restarts the escalation chain. It is a good default for high-urgency services, with one caveat — during a long incident the responder is genuinely working and will get re-paged, so the timeout should be long enough not to interrupt real work, and responders should know to expect it rather than resolve the incident just to make it stop. ## Ack versus resolve These are different claims and confusing them corrupts your incident data: - **Acknowledge** = a human owns this now. The condition is probably still true. - **Resolve** = the condition is over. Most alerting integrations resolve automatically when the underlying signal clears, which is the healthy pattern. Manually resolving a page you have not fixed makes each recurrence look like a brand-new one-off. That destroys the recurrence count, which is the evidence you need when arguing that an alert is noisy or that a service needs real remediation work. ## What good ack behaviour looks like - Ack fast, then say something in the incident channel — even "looking, nothing yet" — so humans as well as the tool know it is owned. - If it turns out to be someone else's problem, escalate or reassign explicitly rather than dropping it. - If you ack and then realise you cannot continue, hand it off out loud and let the next person ack. - Treat time-to-acknowledge as a metric worth watching, but never optimise it by acking reflexively — a good median TTA with a terrible time-to-first-action is a team quietly gaming the pager. ## Why interviewers ask this It is a cheap test for whether you have actually carried a pager. Someone who has will describe ack as ownership and will volunteer the ack-and-sleep failure unprompted. Someone who has only read about on-call describes it as a notification receipt.