On this page3 sections
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.