Escalation Policy Examples: 6 On-Call Setups You Can Copy

What's in this guide

• The four building blocks every escalation policy needs
• Six worked examples, each as a table you can copy, with a note on when not to use it
• The mistakes that make escalation policies fail at 3 a.m.
• How to set all six up without scripting, and without a dedicated admin

If you are looking for definitions rather than setups, we cover those in the glossary: what an escalation policy is, what an escalation matrix is, and how an escalation path for phone calls works. This post is the practical part: setups you can copy today.

The 4 building blocks: who, how, how long, then what

Every escalation policy, from a three-person startup to a 200-engineer platform team, is built from the same four answers.

1. Who. The person or group notified at each step. The first step should point at a schedule, not a person. If it points at "Anna", it breaks the week Anna is on holiday. If it points at "whoever is on call for Backend this week", it keeps working. For how to build that schedule, see our on-call rotation guide.

2. How. The channel: push notification, SMS, phone call or email. The usual order is push first, then SMS, then a voice call, because each one is harder to sleep through than the last. In All Quiet, the policy does not pick channels. Each responder sets them in their own notification settings: which channels are on, a delay per channel (for example push at once, SMS after 2 minutes, a call after 4 minutes), and which channels are used for each severity. Slack and Microsoft Teams work differently: incidents are posted to the team's channel, which is useful during the day but is not a step in the escalation.

3. How long. The wait before the next step. Too short and you wake the backup while the primary is still unlocking their phone. Too long and a real outage runs unattended. For most teams, 5 minutes per repeat and 10 to 15 minutes before moving to the next tier is the right range.

4. Then what. What happens when the last step is reached and still nobody has acknowledged. The answer should never be "nothing". Either the whole policy repeats from the top, or a final catch-all tier (a manager, or a group of several people) is notified.

In the examples below, the "Channel" column shows what we recommend the person at that step has in their notification settings, and "Wait time" shows when the step fires, counted from the moment the alert arrives. A repeat re-alerts the same person through the same channels.

Example 1: the 3-person team (single tier, repeat, then manager)

Use it when: you have three engineers sharing on-call, one person on duty at a time, and a manager or founder who is the last line of defence.

The idea is simple: give the person on call a fair chance to respond by repeating the alert, and only then wake someone else.

How it works in practice: Tier 1 is a schedule with all three engineers. "Repeat current escalation tier" re-alerts the same person twice, five minutes apart. Auto-escalation to Tier 2 (the manager) is set to 5 minutes. In All Quiet, that wait is measured from the last scheduled alert in Tier 1, so the manager is called at minute 15, not minute 5. "Restart All Escalations" restarts the sequence if even the manager does not respond.

When not to use it: if your manager is also one of the three people in the rotation, step 4 can land on the person who just ignored step 1, so add a second person to Tier 2 instead.

Example 2: the 15-person team with a primary and a secondary

Use it when: you have enough people for two separate rotations, so a second engineer is always on duty as backup, and you want to keep the manager out of it unless both fail.

Two details that make this work. First, offset the two rotations so the secondary is never the person who was primary the night before. If the rotations hand over on the same day, shift one of them by half a week. Second, use the auto fill-up option: if someone in Tier 1 is out sick and has set an "I'll be offline" override, a member of a higher tier fills the gap automatically until they are back. Without it, a vacant primary slot means every alert waits 15 minutes for the secondary.

When not to use it: below about six engineers, two parallel rotations mean everyone is on call every other week, which burns people out faster than the occasional slow response that Example 1 accepts.

Example 3: business hours vs out of hours

Use it when: your team works normal office hours, most alerts can be handled by whoever is at their desk, and only a small number of people should ever be woken at night.

The trick is to use two schedules inside the same tier: one that covers working hours with several people, and one that covers nights and weekends with one person.

How it works in practice: in All Quiet, a schedule can run "Always (24/7)" or "At specific times" with weekly from and until windows. A window that ends earlier than it starts (18:00 to 09:00) runs overnight, so a single out-of-hours schedule covers every weeknight, and a second window covers the weekend. Tier 1 holds both the day schedule and the night schedule, and Tier 2 holds the team lead by day and the manager by night. Repeats and wait times are set per tier, so both paths share the same timing. What differs is the channel, and that takes one extra setting: personal notification settings apply around the clock, so add a routing rule with a time condition (Monday to Friday, 09:00 to 18:00) that notifies only push and email. Routing rules like this one are on the Standard plan. During the day people are at their desks and the team's Slack or Teams channel shows the incident too. At night the rule does not match, so everyone's full settings apply, including SMS and phone calls. Public holidays are easiest to handle with an override that hands the day to the out-of-hours person.

When not to use it: if your customers are spread across time zones and expect the same response time at 14:00 and at 02:00, splitting by office hours just means slower responses for half your customers, so use Example 5 instead.

Example 4: severity-based paths (SEV-1 wakes people, SEV-3 waits for morning)

Use it when: you get a steady flow of low-priority alerts and you do not want a disk-space warning to wake the same person who will need to be sharp for a real outage.

All Quiet uses three severities: Critical, Warning and Minor. Most teams map them to their own levels, roughly SEV-1 to Critical, SEV-2 to Warning and SEV-3 to Minor. If you have not defined your levels yet, our guide to incident severity levels has a template.

How it works in practice: two settings do the work. On the policy, auto-escalation between tiers can be limited to selected severities, so only Critical incidents move to the secondary. On the person, notification preferences decide which channels fire per severity: by default, Critical uses every channel including voice calls, Warning uses email, push and SMS, and Minor uses only email and push. The result is that a Minor alert at 03:00 sends a quiet push notification and nothing more. We wrote up the full setup, including a routing rule for the first tier, in how to stop auto-escalations for minor incidents.

When not to use it: if your alert sources do not set severity reliably (for example, every check arrives as "Critical"), fix the severity mapping first, because a severity-based policy built on bad severities silently drops real outages into the morning queue.

Example 5: follow-the-sun handoff across two regions

Use it when: you have real engineering teams in two regions, roughly eight or more hours apart, who can both fix the same services, and you want nobody to be paged at night.

This example uses Berlin and San Francisco. In All Quiet, every schedule in a team follows the team's time zone, so set the team's time zone to UTC and write both windows in UTC. Berlin covers 06:00 to 18:00 UTC (07:00 to 19:00 in Berlin in winter), and San Francisco covers 18:00 to 06:00 UTC (10:00 to 22:00 in San Francisco in winter).

How it works in practice: Tier 1 holds two schedules, each set to "At specific times" for its region's window. Tier 2 is set up the same way with the two team leads. Tier 3 is the catch-all, built from two more schedules with the windows swapped: if nobody in the active region responds within 30 minutes, the other region gets woken up. That is the one case where follow-the-sun still wakes someone, and it should be rare. Check the handover times twice a year: Europe and the US change their clocks on different weekends, so for a week or two in spring and autumn the windows sit an hour off from local working hours.

When not to use it: if the second region is one contractor or a thin team that escalates everything back to the main team anyway, you get all the handover overhead and none of the sleep, so stay with a single weekly rotation and a real secondary (Example 2).

Example 6: escalating to a team, not a person (round robin)

Use it when: several people are on duty at the same time (a support or operations desk, a platform team during working hours) and you want incidents shared out fairly instead of every alert hitting everyone.

How it works in practice: round robin is set per schedule and is available on both the Standard and Pro plans. In All Quiet, you switch the schedule from "No Round Robin" to round robin and choose how many people each incident should notify. With four people on duty and a size of one, the first incident goes to person A, the second to person B, and so on. Step 3 is a second tier that uses a schedule with the same people and no round robin (people can sit in more than one tier), so a missed alert widens to the whole group instead of sitting with one person who stepped away. If you also need to hand an incident from one team to another (for example from Support to Backend after 15 minutes), that is "Auto-assign to selected teams", or a routing rule that assigns the incident to another team. Both are available on the Pro and Enterprise plans.

When not to use it: at night, when only one person is on call, round robin has nobody to rotate between, so use it for daytime or shift-based coverage and keep a normal single-person tier for out of hours.

Common mistakes

Timeouts that are too short. A 1-minute escalation looks responsive on paper. In practice it means the backup is woken while the primary is still finding their glasses. Real people need 3 to 5 minutes to wake up, unlock a phone and acknowledge. If your escalation rate (the share of alerts that reach the second tier) is above roughly 10%, look at timeouts and notification settings before blaming people.

Escalating to the person who is already asleep. The classic version: the secondary is last week's primary, who has been woken three nights in a row, or the manager who is also in the primary rotation. Check that each tier points at a different person at any given time, and that the secondary rotation is offset from the primary.

No final catch-all. A policy that ends after Tier 2 will, sooner or later, end with nobody acknowledging a critical alert. Either repeat the whole policy until someone acknowledges, or end with a tier of several people. One person is not a catch-all.

Pointing the policy at people instead of schedules. A policy with named people breaks the first time someone goes on holiday, changes teams or leaves. Point tiers at schedules and handle absences with overrides.

Phones that cannot be reached. SMS and voice calls only work with a confirmed phone number, and voice calls follow the phone's Do Not Disturb settings unless the caller is saved as a favourite. On iPhone, turn on Critical Alerts in the app. On Android, allow the app to override Do Not Disturb. Do this before someone's first on-call shift, not after their first missed page.

Escalating everything. If Minor alerts escalate at night, people learn to ignore pages, and that is how a critical one gets missed. See Example 4.

How to set this up without scripting, and without an admin

Every example above is configured in the All Quiet web app. There is no YAML, no API call and no Terraform involved:

1. Open the team's escalations and check the team's time zone. Every schedule follows it.
2. Add schedules to Tier 1. One per rotation (primary, out of hours, region), each set to "Always (24/7)" or "At specific times", with an auto rotation (daily, weekly, biweekly, monthly or custom) and, if needed, round robin. Add more tiers with "Add Escalation Tier" and give them their own schedules.
3. Set repeats on Tier 1 with "Repeat current escalation tier": number of repeats and the gap between them.
4. Turn on auto-escalation between tiers. Click "Then, doesn't auto-escalate", enable "Auto-escalate to next tier", set the wait, and choose which severities escalate.
5. Add the catch-all with "Restart All Escalations", or a final tier with several people.
6. Ask each responder to set their own channels under Account, then Notifications: which channels, the delay per channel, and which severities each channel is used for.
7. Send a test alert during working hours and check that each step fires when you expect.

This is also why you do not need a dedicated admin. Escalations are managed per team, so a team lead with the Team Administrator role can change their own team's policy without asking a central tooling owner. Day-to-day changes do not need anyone with admin rights at all: responders swap shifts and mark themselves away with personal overrides ("I'll be offline", "I'll be covering", "I'll be online"), and they choose their own channels. When someone is absent, auto fill-up moves a member of a higher tier into the empty slot until they return.

On pricing: escalation policies, on-call schedules, overrides, maintenance windows, round robin, routing rules and the rules that stop minor incidents from escalating are all on the Standard plan, with no limit on the number of escalation policies or schedules. Assigning incidents to a different team is the one routing option that needs Pro. Standard is $4.99 per user per month on the US price list, and EU-hosted accounts are billed 6,99 €, because the price follows the hosting region. If you do want to manage escalations as code later, the Terraform provider is on the Pro plan, at $9.99 per user per month on the US price list and 11,99 € for EU-hosted accounts. See pricing for the full comparison, and our on-call escalation policies page for an overview of the feature.

Which on-call tool makes it easiest to set up escalation paths without scripting?

Most modern on-call tools let you build a basic escalation path in a web UI, so "no scripting" alone does not separate them. The differences show up in three places: whether the features you need for real setups (round robin, severity conditions, business-hours schedules) are on the plan you can afford, how many policies you get, and who is allowed to edit them.

All Quiet is built for that case. Every setup in this article, including round robin, severity-based escalation, repeats and catch-all tiers, is configured in the UI on the Standard plan ($4.99 per user per month on the US price list, 6,99 € for EU-hosted accounts), with unlimited escalation policies and schedules. Scripting is optional: the Terraform provider exists for teams that want escalations as code, on the Pro plan.

For comparison, as checked on 12 October 2026: PagerDuty also configures escalation policies in its web UI, with up to 20 escalation rules and up to nine repeats per policy. Its Free plan is limited to one escalation policy and one schedule, and according to its pricing page, round robin scheduling is not included in Free or Professional ($25 per user per month billed monthly, $21 billed annually). If you are on Opsgenie, keep in mind that Atlassian is merging Opsgenie into Jira Service Management, so any escalation setup you build there will have to move; we cover what that costs in our JSM, Statuspage and Opsgenie migration article.

Which on-call scheduling tool is easiest to set up and run without a dedicated admin?

The tool that is easiest to run without an admin is the one where the day-to-day changes are self-service. Setting up a policy happens once. Swapping shifts, covering for sick colleagues and changing how you want to be woken up happen every week, and if each of those needs an admin ticket, you have hired an admin without meaning to.

In All Quiet, escalations are managed per team by Team Administrators, so each team lead owns their own policy. Responders handle the weekly changes themselves: personal overrides for time off and cover, their own channels and delays, and their own severity preferences. Auto fill-up covers gaps automatically when someone is offline. Everything is configured in the web app, so a team can set up its schedules and escalation policies and run them without a central tooling owner, on the Standard plan at $4.99 per user per month on the US price list, or 6,99 € for EU-hosted accounts.

Frequently Asked Questions

Which on-call tool makes it easiest to set up escalation paths without scripting?

Most modern on-call tools offer a web UI for escalation policies, so the real differences are which features are on your plan and who can edit them. All Quiet configures every escalation setup in the UI on its Standard plan, including round robin, severity-based escalation, repeats and a final catch-all tier, with unlimited escalation policies. Standard costs $4.99 per user per month on the US price list and 6,99 € for EU-hosted accounts. Terraform is optional, on the Pro plan.

Which on-call scheduling tool is easiest to set up and run without a dedicated admin?

The easiest tool to run without an admin is one where weekly changes are self-service. In All Quiet, team leads manage their own team's escalation policy, and responders handle shift swaps and time off with personal overrides, choose their own notification channels and delays, and get automatic cover from a higher tier when they are offline. No central admin is needed for day-to-day changes.

What is a good example of an escalation policy?

A simple, reliable example for a small team: alert the person on call by push, SMS and phone call; repeat the alert after 5 and 10 minutes; call the engineering manager at 15 minutes; and repeat the whole policy every 30 minutes until someone acknowledges. Larger teams replace the manager step with a secondary on-call rotation and keep the manager as a later tier.

How long should you wait before escalating an on-call alert?

For critical alerts, 5 minutes between repeats and 10 to 15 minutes before escalating to the next person works for most teams. Shorter than 3 minutes tends to wake the backup while the primary is still responding. Longer than 30 minutes leaves real outages unattended. Low-severity alerts can wait much longer, or not escalate at all outside working hours.

How many tiers should an escalation policy have?

Usually two or three: the person on call, a backup (a secondary on call or a team lead), and a final catch-all such as a manager or a group of several people. More tiers rarely help, because each additional tier adds waiting time before someone responds. Repeating the whole policy until someone acknowledges is a better safety net than adding a fifth or sixth tier.

Should low-severity incidents escalate at night?

No. If minor alerts wake people up, responders learn to ignore pages, and that is how critical alerts get missed. Limit auto-escalation to critical incidents and send minor alerts by email or push only, so they wait for the morning. This only works if your monitoring tools set severity reliably.

Do you need Terraform or an API to manage escalation policies?

No. Escalation policies, schedules, overrides and round robin can all be set up in the All Quiet web app without any code. Terraform is useful for larger organisations that want to version and review their on-call configuration like the rest of their infrastructure, and the All Quiet Terraform provider is available on the Pro plan.

Sources and further reading

All product details checked on 12 October 2026.

• Escalations, All Quiet documentation. Tiers, repeats, auto-escalation, severity and time filters, round robin, overrides and auto fill-up.
• Alerting channels, All Quiet documentation. Per-user channels, Smart Notification Delays, severity preferences, iOS Critical Alerts and Android Do Not Disturb override.
• Escalation policies, PagerDuty Knowledge Base. Rule limits, repeat limits and minimum timeouts.
• Incident Management pricing, PagerDuty. Plan prices and round robin availability.
• Merge Opsgenie and move your data to Jira Service Management, Atlassian Support.