Escalation Policies: How Many Steps, and How Long to Wait Between Them
An escalation policy is the part of an on-call setup nobody thinks about until it fails them. 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.
Most broken escalation policies fail for one of two reasons: not enough steps, or wait times that assume everyone responds like it's the middle of a work day.
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.
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 steps is enough
For most small teams, three steps covers it:
- 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.
Tuning wait times for 3am, not 3pm
This is 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.
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. 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.