How to design an escalation policy
Levels, waits, targets and repeats in an escalation policy, with example policies, common mistakes and a checklist.
Published 30 September 2026.
An escalation policy answers one question: if nobody responds, who hears about it next, and when? A good policy is short. It points at schedules rather than people. It has waits long enough to act on but short enough that an outage does not run for an hour unnoticed.
The decisions
How many levels
Most teams need two or three levels.
- Level 1: the primary on-call schedule.
- Level 2: a secondary schedule, or the whole team if you do not run a secondary.
- Level 3 (optional): a team lead or engineering manager. This level exists so that a missed page becomes someone's problem to sort out, not so that the manager fixes the outage.
More levels rarely help. If three levels in a row do not answer, the problem is the rota or the notification settings, not the policy.
How long to wait at each level
The wait is the time from notifying a level to moving on to the next one. Common values are 5 to 15 minutes for urgent alerts. Think about what the person has to do to acknowledge: wake up, find the phone, open the app. Five minutes is tight at 3am. Thirty minutes is a long outage.
Some tools let the wait differ per level. A short first wait and a longer second one is a common shape.
Who each level targets
Point levels at schedules, not named people. When the rota changes, the policy keeps working. Target named people only for roles that do not rotate.
A level can target several things at once, such as a schedule and a chat channel. Notifying a whole team at level 1 is tempting, but it spreads the responsibility: when everyone is paged, each person assumes someone else has it.
Repeat or stop
When the last level has been notified and nobody acknowledged, the policy can stop or start again from level 1. Repeating once or twice is sensible for urgent alerts. Repeating forever creates noise and hides that the policy failed.
Urgency
Not every alert should use the same policy. A common split:
- High urgency: notifies immediately, by phone or push, at any hour, and escalates.
- Low urgency: notifies in working hours only, by chat or email, and does not escalate at night.
Tie urgency to severity. An alert for a full outage and an alert for a disk at 80% should not wake the same person the same way.
Example policies
These are starting points. Adjust the waits to how fast your service needs a response.
A single rota of four to six people
| Level | Target | Wait |
|---|---|---|
| 1 | Primary schedule | 10 minutes |
| 2 | Whole team | 15 minutes |
| Repeat | Once, from level 1 |
Primary and secondary
| Level | Target | Wait |
|---|---|---|
| 1 | Primary schedule | 5 minutes |
| 2 | Secondary schedule | 10 minutes |
| 3 | Engineering manager | 15 minutes |
| Repeat | Twice |
Follow the sun
| Level | Target | Wait |
|---|---|---|
| 1 | Schedule of whichever region is in working hours | 10 minutes |
| 2 | The other region's on-call schedule | 15 minutes |
The second level wakes someone up, so it should be rare. See follow the sun.
Mistakes to avoid
- Everyone at level 1. Diffuses responsibility and wakes the whole team for every alert.
- Named people instead of schedules. Breaks silently when someone leaves or goes on holiday.
- One policy for every alert. Low-priority alerts escalate at night and train people to ignore pages.
- Waits shorter than it takes to acknowledge. The page escalates before the first person could reasonably answer.
- No test. Trigger a test alert after every change and follow it through every level.
Checklist
- Every service has exactly one escalation policy.
- Every level points at a schedule or a role, not a person.
- Waits have been tried against a real 3am acknowledgement.
- Urgent and non-urgent alerts use different policies.
- The policy repeats a set number of times, then stops.
- Someone reviews missed escalations each week.
Tools that run escalation policies are in the on-call directory.