On-Call Escalation Policy Template: Three Copy-Paste Policies That Actually Get Someone Out of Bed (2026)

At 2:14am a disk-full alert fires for a client's primary file server. It lands in a shared inbox, a Slack channel and one engineer's phone, on silent. Three people could have seen it. Each assumed someone else had it. The client found it at 7:30am, and so did the account manager. An escalation policy template exists to make that story impossible: it writes down, in advance, who gets woken, in what order, over which channels, and how long each person has to acknowledge before the alert moves on to the next.

This post gives you three complete, copy-pasteable escalation policies: one for a two-person MSP, one for an eight-person NOC, and one for a 24/7 multi-client operation. They are genuinely usable in any paging tool, or on paper. Along the way we cover the severity tiers the timings hang off, the numbers the industry has converged on, and the five ways escalation policies quietly fail.

One pair of numbers frames everything that follows. The default escalation timeout in PagerDuty, the tool that popularised the concept, is 30 minutes. Google's SRE book notes that a service promising 99.99% availability has a downtime budget of around 13 minutes per quarter. If your policy waits longer for one person than your whole quarter can afford, the policy is where the outage gets expensive.

What an escalation policy actually is

Strip away the vendor UI and every escalation policy is four moving parts:

• Levels. An ordered list of who gets notified. Level 1 is usually the person currently on call. Level 2 is a backup, a secondary rotation or a lead. The last level is the backstop: someone who answers even when everything above them failed.
• Targets.Who each level actually points at. The good ones point at a rotation ("whoever is on call for Team A right now"), not a named person, so the policy survives holidays and resignations.
• Timeouts. How long each level has to acknowledge before the alert moves on. This is the number that decides your worst-case time to a human.
• Repeats. What happens when the last level is exhausted: loop the whole policy again, or stop. Stopping silently is how alerts die.

The mechanics in real tools are worth knowing even if you never use those tools, because they encode two decades of hard-won defaults. In PagerDuty's implementation, verified against its own documentation in August 2026, level 1 fires instantly: "There is no delay before this first notification." The escalation timeout defaults to 30 minutes and can go as low as 1 minute for a single target (3 minutes when a level notifies several people), a policy can hold up to 20 escalation rules, and it can repeat up to 9 times before it stops. Those limits tell you what the extremes look like. The templates below stay far away from them on purpose: nobody needs 20 levels, and a policy that needs 9 repeats has a staffing problem, not a configuration problem.

Severity tiers come first

You cannot write escalation timings until you have decided what deserves them. Every mature incident process starts by classifying severity, then attaches a response to each class. PagerDuty's public incident response documentation, for example, defines five tiers, from SEV-1 (critical, wide customer impact, all hands) down to SEV-5 (cosmetic, handle via the ticket queue), and its guidance on ambiguity is the right instinct: when you are not sure which severity an incident is, treat it as the higher one and downgrade later.

Five tiers is more than most MSPs need. Four is enough, and the fourth exists mainly to stop the other three being polluted:

The MSP twist, and the reason you cannot copy an enterprise severity matrix wholesale, is that severity is per client. The same "server unreachable" alert is a SEV-1 for the medical practice whose booking system lives on it and a SEV-3 for the landscaping company that will not touch a computer until Monday. Template 3 below deals with this directly. If your alerts arrive faster than you can classify them, that is a noise problem before it is an escalation problem; our guide to RMM alert management for MSPs covers the routing and filtering layer that should sit in front of any policy on this page.

The numbers that matter

Google's SRE book, still the most-cited reference on paging discipline, describes two response-time tiers for paged incidents: "5 minutes for user-facing or otherwise highly time-critical services" and 30 minutes for less time-sensitive systems. Those two numbers map cleanly onto SEV-1 and SEV-2 above, and they are the anchor timings in all three templates.

The arithmetic people miss is that timeouts add up. Your worst-case time to a human is the sum of every level's timeout, not the first one. A policy of three levels at 15 minutes each means a SEV-1 can sit unacknowledged for 45 minutes while behaving exactly as designed. Run that sum for every policy you write, then compare it against the response time in your client contracts. If your managed services agreement promises a 30-minute response to critical issues and your escalation chain can legally take 45, the policy fails your SLA by design, and no amount of engineer diligence fixes a broken timer.

Template 1: the two-person MSP

Honesty first: the SRE book says a sustainable single-site on-call rotation needs about eight engineers, six if you split across sites. Most MSPs reading this have two, and no amount of best-practice literature changes that. So this template does the opposite of the textbook: instead of stacking people it stacks channels, hitting the same person harder before involving the only other human available.

Written as prose, for the version you paste into your runbook: a SEV-1 pages the on-call engineer on every channel at once and gives them five minutes. If nothing comes back, the second engineer gets five minutes. Still nothing, the whole cycle runs twice more with voice leading. Worst case, a SEV-1 has rung two phones repeatedly for half an hour before it exhausts, and in a two-person shop, if thirty minutes of ringing reaches nobody, there is no third person a longer policy would have found. SEV-2 is the same shape at a gentler tempo. SEV-3 and SEV-4 never page after hours, and defending that line is what keeps the first two tiers believable.

Two rules make this template survivable. First, the phone must be able to break through: an on-call phone on silent turns the whole policy into decoration, so use critical alert or override-DND settings on whichever platform your engineers carry. Second, the repeat cap is deliberate. When the policy exhausts, it should fail loudly into the morning, at the top of a structured on-call handover, never silently into an unwatched queue.

Template 2: the eight-person NOC

Eight engineers is the size the SRE book considers sustainable, and the extra headroom buys you real structure: a primary rotation, a secondary rotation offset from it, and a duty manager tier that only ever hears about genuine failures. The timings tighten because nobody is being asked to be reachable every night of the year.

The design decisions worth stealing even if your numbers differ: the secondary is a real rotation with its own roster, not "whoever answers the group chat", and it is deliberately offset so the same person is never primary and secondary in the same week. The duty manager hears about a SEV-1 only after ten minutes of silence from two engineers, which keeps that tier meaningful. And during business hours, SEV-3 flows through a round-robin so daytime volume is shared instead of landing on whoever happens to be on call for the nights. At this size the quiet failure mode is unfairness rather than missed pages: rotations drift, one engineer ends up carrying the worst weeks, and nobody notices until they resign. Measuring that load is its own topic, covered in our hidden cost of MSP shift changes research.

Template 3: the 24/7 multi-client operation

Once you run true 24/7 coverage across many clients, two things change. Escalation targets must be roles resolved at page time ("current on-call for the covering shift"), never named people. And severity stops being a property of the alert alone: it is a function of the alert and the client it belongs to.

The per-client severity map

Before the policy itself, this operation needs a mapping table that your alert routing applies before anything pages:

The policy

Three rules complete this template. Maintenance windows are part of the policy:when your own team patches a client's servers on Saturday night, the resulting storm of expected alerts must be suppressed for that client, for that window, with SEV-1 heartbeat-style checks as the only exception. Unsuppressed maintenance noise is how night shifts learn to ignore pages. Shift boundaries need an explicit rule:an alert acknowledged at 6:40am but still open when the shift changes at 7:00am must carry into the incoming engineer's handover brief with its acknowledgement history intact, otherwise it is nobody's problem the moment its owner goes to sleep. And the sum rule still applies per client: check the SEV-1 chain against the tightest SLA in the critical tier, not the average one.

Five ways escalation policies fail

1. Too many levels. If your policy needs five or six levels, level 1 is wrong. Every extra level adds its timeout to the worst case and dilutes ownership. Two or three levels plus a repeat covers almost every real organisation; the 20-rule ceilings in commercial tools are limits, not targets.

2. Timeouts that outrun the SLA. The sum rule again. This is the most common failure in MSP policies because the policy and the client contract are written by different people in different years, and nobody has ever put them side by side.

3. Escalating to a group. A distribution list, a shared inbox or a channel is not an escalation target. When five people are notified, each of them knows four others were too, and the 2:14am story at the top of this post plays out. Every level should resolve to exactly one accountable human; if you want several people aware, notify them, but assign one.

4. No backstop behaviour.Decide, explicitly, what happens when the last level times out and the repeats are spent. The wrong answer is the default in most tools: the alert stays assigned to the last responder and goes quiet. The right answer is that it fails loudly somewhere guaranteed to be looked at, which for most MSPs means the top of the next shift's handover brief.

5. Never testing it. Policies rot. People leave, numbers change, a notification integration silently loses a permission. Fire-drill each policy quarterly: raise a synthetic SEV-1 out of hours, let it escalate at least one level, and time the result. Twenty minutes of scheduled annoyance per quarter is cheap against discovering a dead phone number during a real outage.

Running the template in a real tool

Any of these policies can run on paper plus discipline, and a two-person shop can genuinely operate template 1 from a laminated card and a loud phone. What a tool adds is the part discipline cannot do: resolving "current on-call" from a live roster at 2am, firing the channels in order, counting the timeouts, and recording who acknowledged what and when. If you are evaluating options, our guide to on-call software for MSPs scores the market on an MSP-specific rubric.

For transparency about where we sit: Shiftctl Enterprise implements this whole loop. Alerts from your RMM or monitoring arrive by webhook, the per-client mapping assigns severity, the alert routes to whoever the roster says is on call right now, and escalation runs over SMS, voice call with press-1 acknowledgement, Slack, email and push until someone acknowledges, from the web, a Slack button, an SMS reply or an email link. The piece the templates above call the backstop is native: anything still open at shift end carries into the incoming engineer's handover brief automatically, with its acknowledgement history attached. The honest caveats: alert routing and escalation live on the Enterprise plan, not Team, and Shiftctl has no inbound number clients can dial. If a contract requires a phone line a person answers, run a dialer-based tool alongside Shiftctl for that piece. Setup details are in the docs, and per-seat pricing is on the pricing page.

Frequently asked questions