Escalation Policies: How Many Steps, and How Long to Wait Between Them

A good escalation policy needs at least three steps, with wait times tuned for 3am rather than the middle of a work day. Most broken policies fail because they copy a default template with too few steps and wait times that assume someone answers within a minute of being paged.

The rotation gets attention. The schedule gets attention. The policy that decides what happens when the first person doesn't answer usually gets copied from a default template and never touched again — right up until a 3am incident sits unacknowledged for twenty minutes because it never reached anyone.

Start with the failure case, not the happy path

It's tempting to design an escalation policy around the common case — the on-call engineer sees the page, acknowledges it, handles it. That case doesn't need a policy at all; a single notification would do. The entire point of escalation is the case where that doesn't happen: phone on silent, dead battery, asleep through a push notification, or simply mid-incident on something else already. This is the same failure-first framing Google's SRE book uses for on-call design generally: build for the page that doesn't get acknowledged, not the one that does.

Design for that case first. Ask: if the primary on-call person doesn't respond in five minutes, who's next? If that person doesn't respond either, then who? A policy with only one fallback step is a policy that assumes a single point of failure never fails — which is exactly backwards for the tool whose entire job is handling failure.

How many escalation steps should a policy have?

Three, for most small teams. That covers a primary responder, a genuine backup, and a final backstop without adding so many steps that nobody remembers who's actually in the chain:

• Step one — the primary on-call engineer, immediately.
• Step two — a secondary on-call engineer or the rotation's designated backup, after a short wait.
• Step three — a team lead or manager, as a final backstop.

Two steps is the bare minimum — anything less means one missed notification stalls the whole incident. Beyond four or five steps, policies tend to get complicated enough that nobody fully remembers who's in them, which defeats the purpose just as thoroughly as too few steps.

A common mistake worth calling out directly: putting a manager or team lead at step one instead of step three. The instinct is understandable — a manager feels like the "responsible" party — but a manager mid-meeting or traveling is no more reliable than anyone else, and burning the final backstop's attention on alerts a primary responder should be catching leaves nowhere to go once it's actually needed. The backstop should stay a backstop.

Tuning wait times for 3am, not 3pm

Wait times before escalating are where most policies quietly fail. A five-minute wait before escalating feels reasonable when you're picturing someone at their desk. It feels very different to someone who's asleep — five minutes is roughly the time it takes to wake up, find a phone, and register what's happening, not the time it takes to act on it.

A reasonable default is closer to seven to ten minutes for the first escalation step, especially for anything that isn't immediately customer-facing. For genuinely critical alerts — a full outage, a payment system down — shorter wait times are justified, but they should be the exception applied deliberately, not the default applied everywhere. It's worth setting different wait times for different severities rather than one blanket number for every alert type, since a policy tuned for the rare full outage ends up escalating routine alerts too aggressively, and a policy tuned for routine alerts leaves a real outage sitting too long before anyone else is notified.

The mechanism matters as much as the policy

An escalation policy is only as good as the notification method behind it. A policy that escalates correctly but only sends a silent push notification at every step hasn't actually solved the problem — it's just failed three times instead of once. This is why PingParrot pages repeat and escalate through multiple channels rather than sending a single notification and hoping: a page keeps alerting — with iOS critical alert and Android alarm-style delivery that bypasses Do Not Disturb — until someone actually acknowledges it, and only then does the clock reset.

Review the policy against real incidents, not hypotheticals

The best test of an escalation policy isn't a tabletop exercise — it's your actual paging history. This mirrors how PagerDuty's own public incident response documentation recommends running a post-incident review: against what actually happened during a real page, not a hypothetical one. Pull the last handful of real incidents and ask: did the policy escalate the way you expected? Was anyone paged who shouldn't have been reachable at that step? Did an incident ever reach the final fallback step, and if so, was that person actually prepared to handle it cold?

An escalation policy that's never been checked against real data is a policy that's untested by definition. Treat it the way you'd treat any other piece of production configuration — reviewed periodically, updated when the team changes, and never assumed to be correct just because nobody's complained yet. A quarterly review is a reasonable cadence for most small teams: often enough to catch a policy that's drifted out of sync with who's actually on the team, infrequent enough that it doesn't become its own recurring chore nobody takes seriously. The team that skips this review entirely is usually the same team that discovers its escalation policy is broken during the incident it was supposed to handle, which is the most expensive possible time to find out.