What is an escalation policy? Levels, waits and 3 worked examples

An escalation policy is the ordered list of who gets notified about an alert, through which channel, and how long to wait before moving to the next person or channel if nobody acknowledges. Each step is a level with a target and a wait in minutes; the chain runs until someone acknowledges the alert or the levels are exhausted, and optionally repeats. It is the part of on-call that turns “an alert fired” into “a named person is now working on it”.

The policy needs to be written down and executed by software because the manual version fails in exactly the situations it exists for. A Slack message at night with nobody watching the channel is not an escalation, and neither is a monitoring tool that emails the same address forever. This post covers the anatomy of a policy, three example policies as tables you can copy, the mistakes that quietly break them, and how to test one. It is the “what to do with the alert” side of on-call; the “who is on duty” side is in how to create an on-call schedule and the on-call roster guide.

What is an escalation policy made of?

A policy has two parts: an immediate notification that goes out when the alert triggers, and an ordered list of escalation levels that fire one at a time while the alert stays unacknowledged.

The immediate notification is the “first knock”. It usually goes to a team-visible channel like a Slack channel or shared inbox, and fires on three events: trigger, acknowledge, and resolve. Sending all three to the same place gives the team the whole lifecycle of the alert without anyone posting status updates by hand.

The escalation levels are where the policy earns its keep. Each level has:

Part	What it means	Typical value
Wait	Minutes to wait after the previous step before this level fires	5, 10, 15, 30
Target	Who or what this level notifies	The current on-call from a roster, a named person, a channel, a webhook
Channel	How the target is reached	Email, Slack, Telegram, WhatsApp, SMS, mobile push, or the person’s own preferences
Enabled	Whether the level is currently active	On, or toggled off during maintenance

Two further settings apply to the whole chain:

• Repeat: whether to start again from level 1 after the last level fires without acknowledgement.
• Repeat max: how many times the loop is allowed to run before it stops.

The important design idea is that the target and the channel are separate choices. “Page the on-call” is a target. “By SMS” is a channel. Keeping them apart lets one policy say “reach whoever is on duty, however they prefer” rather than hardcoding a phone number that stops being correct the day the rota changes.

Who should each escalation level target?

Point most levels at a roster, not at a named person, so the policy keeps working as people rotate in and out.

There are four kinds of target worth distinguishing:

1. A roster. The level pages whoever is currently on-call according to the rotation. This is the default choice for the first human level and usually the second. The policy never needs editing when the rota changes.
2. A named person. Useful for a specialist tier (“escalate to the database lead regardless of who is on-call”) or a final catch-all such as a team lead. Use sparingly; every named person in a policy is a person who cannot go on holiday without someone editing the policy.
3. A channel. A Slack channel, a Telegram group, an email address. Good for the first knock and for ambient awareness, poor as the only target of a level, because a channel cannot acknowledge.
4. A webhook. For mirroring the alert into a ticketing system, a status page or a bridge to another tool. Webhooks sit alongside the human chain rather than in it.

Round robin is a fifth option some tools offer: the level rotates through roster members per alert, so consecutive alerts land on different people. It suits daytime alert queues where the goal is spreading load rather than waking one designated person.

For the human levels, a target that follows the person’s own notification preferences (AlertKick calls this “Notify Person”) is worth using: the policy says “reach this person” and the person decides whether that means push, Telegram, SMS or email. The full channel lineup is in the notification channels guide.

How long should each escalation level wait?

Start at 5 minutes between levels for customer-facing services, 10 to 15 minutes for internal infrastructure, and 30 minutes or more for best-effort alerts.

The wait is the time given to the current target to notice, open, and start on the alert. Too short and the second person is woken before the first has unlocked their phone; both then stare at the same screen. Too long and a genuinely missed page leaves a customer-facing outage unattended for the length of the wait. The right number depends on how fast the service degrades, not on how quickly you would like people to respond.

A few practical rules:

• The first human level rarely needs more than 5 minutes for anything critical. The on-call has agreed to be reachable; 5 minutes is enough to acknowledge and say “looking”.
• Gaps between later levels can be longer than the first. By level 3 the problem is “the on-call is unreachable”, not “the on-call is slow”.
• Acknowledging is what stops the chain; it does not mean “fixed”. The on-call should acknowledge first and investigate second.

Waits are measured from the previous level, so a policy with waits of 5, 10 and 15 minutes reaches its third level 30 minutes after the alert fired.

What does a good escalation policy look like?

Below are three policies for three different kinds of service. They differ in how fast they climb, how loud they get, and whether they repeat.

Example 1: critical, customer-facing

For a production API, a checkout flow, or anything with a customer on the other end of it.

Step	Wait	Target	Channel
Notify	0 min	#alerts-prod	Slack, on trigger / ack / resolve
Level 1	5 min	Primary on-call (roster)	Person’s own preferences
Level 2	5 min	Primary on-call (roster)	SMS
Level 3	10 min	Secondary on-call (roster)	Person’s own preferences
Level 4	15 min	Engineering lead (named person)	SMS
Repeat	Yes, max 2

The shape: a visible first knock, the on-call quietly, the on-call loudly, the backup, then the catch-all. The second level re-pages the same person on a more disruptive channel before moving on, because “did not see the push notification” is far more common than “genuinely unreachable”. Repeat is on with a cap, so a missed chain restarts rather than going silent.

Example 2: internal infrastructure

For CI runners, internal dashboards, a staging environment, a build cache. Things that hurt the team but not the customer.

Step	Wait	Target	Channel
Notify	0 min	#alerts-infra	Slack, on trigger / resolve
Level 1	10 min	Infra on-call (roster)	Person’s own preferences
Level 2	15 min	Infra on-call (roster)	SMS
Level 3	30 min	Platform lead (named person)	Email
Repeat	No

Slower climb, fewer levels, and the final level is email rather than SMS: if the infra on-call and their SMS fallback have both been missed on a staging problem, a lead reading email in the morning is an acceptable outcome. No repeat, because the Slack channel keeps the alert visible and the next person to look at it during working hours will pick it up.

Example 3: best-effort

For observability-of-observability, capacity trend warnings, certificate expiry with weeks of notice, and anything whose correct response is “look at it on Monday”.

Step	Wait	Target	Channel
Notify	0 min	#alerts-low	Slack, on trigger / resolve
Level 1	60 min	Team inbox	Email
Repeat	No

One visible notification, one durable record, no human paged. This policy exists so best-effort alerts have somewhere to go that is not the critical policy. A large share of alert fatigue comes from alerts that belong here being on the first policy; see how to reduce alert fatigue on-call for the sorting exercise. Every alert source in your monitoring should map to exactly one of the three, and if you cannot say which, the alert is probably not well enough defined to page anyone.

What are the most common escalation policy mistakes?

The mistakes that break escalation policies are common. They stay invisible until the night they matter.

• Every level points at the same person. A chain that pages one engineer by push, then by Telegram, then by SMS, then by email is not an escalation. It is four ways to not reach one person. At least one level should target somebody else.
• The first level fires too fast. A 1-minute wait wakes the secondary before the primary has found their phone. Five minutes is the floor for the first human wait on most services.
• No repeat on critical policies. If the whole chain runs and nobody acknowledges, a customer-facing alert should not go quiet. Turn repeat on, with a maximum count so it cannot loop forever.
• Named people instead of rosters. The policy was correct when it was written. Then the named person changed teams. Rosters keep the policy correct as people move.
• The loudest channel first. A policy that opens with SMS trains people to dread the pager and then mute it. Visible channel first, personal channel next, disruptive channel last.
• One policy for everything. If certificate warnings and checkout failures both page the on-call at 5 minutes, the on-call learns to ignore pages. The three-policy split above is the fix.
• Levels edited instead of toggled. During planned maintenance, people delete the SMS level and forget to add it back. Toggling a level off preserves its configuration for when the window ends. A maintenance window that suppresses alerts for a scope and time range is better still.
• Quiet hours with no critical bypass. Personal quiet hours are healthy. Quiet hours that also silence a customer-facing outage are a policy gap; critical alerts should be allowed through.

The last two overlap with rotation discipline more than policy design. On-call rotation best practices covers the operating side.

How do you test an escalation policy?

Fire a real alert against a service that uses the policy, do not acknowledge it, and watch every level fire in order with a stopwatch.

A policy that has never been tested end to end has never been tested. The checklist:

1. Create a test service bound to the policy you want to test. Point a monitor at something that will fail on demand: a dead port, a heartbeat that you simply do not send.
2. Let it fail and start a timer. Note when the first notification arrives and where.
3. Do not acknowledge. Let each level fire. For each one, check the channel you expected received the message, and that the gap matched the configured wait.
4. Acknowledge from one place (Slack button, mobile app, whichever the team really uses) and confirm nothing further fires. Acknowledging in one place must stop escalation everywhere; if it does not, the test has found the most expensive bug a policy can have.
5. Resolve and confirm the resolve notification lands where the trigger notification did.
6. Repeat after changes. Any edit to the policy, and any change to the roster it points at, is a reason to run the test again. A new member with no notification preferences set is found by this test, not by a review.

Keep the test service around; it costs nothing and becomes the standard way to verify a change.

How AlertKick handles this

AlertKick escalation policies use default notifications on trigger, acknowledge and resolve, then ordered levels each with a wait in minutes, repeat with a maximum count, and levels that can be toggled off without deleting them. Level types cover Email, Roster (pages the current on-call), Telegram, WhatsApp, SMS, Notify Person (follows that person’s own preferences), Slack, custom webhook and Round Robin. Acknowledging from Slack, the mobile app, Telegram or the web stops escalation everywhere, and per-user quiet hours can let critical alerts through. Escalation policies, rosters and alert ingestion from Prometheus Alertmanager, Grafana, Datadog, CloudWatch and 28+ other sources are included on every plan, including Free, so AlertKick can sit purely as the escalation layer over monitoring you already run. Setup is in the escalation policies guide, and the broader feature set is on the alerting page.