Escalation Policy
An escalation policy defines who gets notified, in what order, and after which timeouts when an alert is not acknowledged — ensuring incidents reach a human who can act before impact grows.
On this page
An escalation policy is the ruleset that routes alerts to people when automated systems detect a problem. It typically names a primary on-call, backups, secondary teams, and time-based escalations if nobody acknowledges within defined minutes.
Escalation is the bridge between monitoring and human response. Without it, alerts sit in a queue; with a bad policy, everyone gets pinged at once — a fast path to alert fatigue.
Why it matters
Clear escalation improves MTTD: the right person is notified once, with urgency matched to severity. It also protects your on-call rotation — secondary and manager steps exist so one tired primary is not the single point of failure. Designing policies is a core topic in How to Build an Effective On-Call Rotation guide.
Example
A production API policy might look like:
- 0 min — page primary on-call (mobile push + SMS)
- 5 min — if unacknowledged, page secondary on-call
- 15 min — escalate to engineering manager and incident commander pool
- Business hours — also notify the service owner Slack channel for visibility
Different services can attach different policies — payments escalate faster than internal admin tools.
Common mistakes
- Escalating to @channel as step one — trains everyone to ignore alerts.
- Identical timeouts for every severity — critical pages need shorter ack windows.
- Dead ends — a policy that pages someone who no longer works on the team.
- No linkage to runbooks — the page should say what to do, not just that something failed.
Document policies with the escalation policy template and review them when rotations change. Test escalations quarterly: a policy nobody has triggered in a year is a guess.