Escalation policy examples: levels, timings and an escalation matrix template

You are setting up on-call and need to decide who gets notified first, who is next, and how long to wait between them. This post defines an escalation policy, gives four example policies with timings, a copyable escalation matrix template, and the mistakes to avoid.

What is an escalation policy?

An escalation policy is an ordered list of who is notified about an incident and how long to wait at each step before notifying the next. It answers one question: if nobody acknowledges this incident, who is notified next, and when? Acknowledging stops the chain.

A policy has four parts. Levels (also called steps, tiers, or rules) define the sequence. Targets at each level are either a person or an on-call rota that resolves to whoever is on call now. A wait is the timeout before the next level triggers. The final rule defines what happens after the last level: stop, repeat from the top, or close the incident.

The guide to building an on-call schedule covers how to set up the rotas that levels point at.

What is an escalation matrix?

An escalation matrix is the same information as a table. Rows are levels. Columns are who, how they are contacted and after how long.

The term is also used in customer support and project management for the list of managers to contact. This post covers incident escalation.

A matrix shows the path an incident takes if nobody acknowledges, so gaps in coverage are visible before an incident finds them. The policy in your on-call tool sends the notifications; the matrix is the design written down.

What are the two types of escalation?

ITIL defines two types of escalation in incident management. Functional escalation passes the incident to a person or team with more specific skill, such as the database team or a vendor. Hierarchical escalation passes it up the management line for authority or visibility, such as to a team lead or head of engineering. An on-call escalation policy is mostly automated functional escalation with a hierarchical last level.

Escalation also differs by what starts it. Escalation by time happens automatically when nobody acknowledges the incident. Escalation by decision happens when the person who acknowledged needs help. They can escalate by hand by reassigning the incident or adding responders.

Escalation policy examples

The timings below are illustrations, not standards.

A basic two-level policy

This suits a single team handling general incidents.

After level 2, repeat the policy once, then leave the incident open.

A three-level policy for a critical service

Use this for services where downtime costs money or damages customer trust.

After level 3, repeat up to 2 more times.

A low-urgency policy

This fits internal tools, batch jobs, or non-critical alerts that can wait for business hours.

After level 2, do not repeat. The incident stays open until someone handles it in working hours.

A follow-the-sun policy

Level 1 is the regional shift that is at work now. If nobody acknowledges within 10 minutes, the primary on-call person is notified. Level 2 is the team lead after a further 15 minutes. The post on the follow-the-sun model covers regional shifts.

How to choose escalation wait times

Set the wait longer than it takes a person to see the notification and open a laptop. Set it shorter than the damage you can accept. Use shorter waits for higher priority incidents. See the incident priority levels post for how to define those priorities.

Add up the waits at each level. The sum is the longest an incident can go unowned in one round. In the basic two-level example, the waits are 10 minutes and 15 minutes. That is 25 minutes for one round. If 25 minutes is more than the business can accept, shorten the waits.

Escalation matrix template

Copy this table into your wiki and fill it in.

Fill it in for each kind of service, and keep it next to the rota.

Escalation policy best practices

• Every level must have someone on call at all times. A level pointing at an empty rota is a hole.
• Point levels at rotas, not at named people, so holidays do not break the policy.
• Never have a single-level policy for anything that matters. With one level, an alert that one person misses reaches nobody.
• Keep the last level a person with the authority to pull in others.
• Use one policy per kind of service. A policy for every service is more to keep up to date.
• Test the policy with a test alert. Let it run to the last level.
• Review it when people join or leave, so no level points at someone who has gone.

Common mistakes

• Notifying everyone at level 1. When five people get the same alert, each assumes another has it.
• Setting waits so long that level 2 never matters. By the time it runs, the damage is done.
• Putting the manager at level 1. The on-call engineer waits for permission instead of acting.
• Letting policies repeat forever. People learn to ignore the alerts.
• Skipping a policy for low-urgency alerts. Without one, minor alerts go to the on-call person like everything else.

How a PagerDuty escalation policy works

In PagerDuty an escalation policy is made of escalation rules, each with targets and an escalation timeout in minutes. The policy can repeat if no one acknowledges, and services point at an escalation policy. The PagerDuty escalation policy docs have the details. The terms in this post map across: rules are levels, and the timeout is the wait.

Escalation policies in OnCallAlerting

An OnCallAlerting escalation policy is an ordered list of 1-10 levels. Each level notifies 1-10 people or rosters at the same time. A roster notifies whoever is on call at that moment. Each level waits 1-1440 minutes before the next. Acknowledging stops the chain.

You can repeat all levels 0-9 more times. If nobody acknowledges after the last round, the policy can resolve the incident automatically. Otherwise the incident stays open. If nobody is on call at a level, the organization owner is notified, so a coverage gap still reaches a person.

The basic two-level example above looks like this in OnCallAlerting:

1. Level 1 notifies the team roster and waits 10 minutes.
2. Level 2 notifies the roster and the team lead and waits 15 minutes.
3. The policy repeats once.

One round takes 25 minutes. The preview shows the path and the total time before you save.

Every alert source and heartbeat points at one policy. Each level notifies in the in-app inbox, or in Slack plus the in-app inbox.

Setup is in the escalation policies docs and the rosters docs. To try it, start a 30-day trial.