Free template

Incident Escalation Matrix Template

Severity levels, escalation paths and a contact roster with backups, so whoever gets paged knows how serious the incident is and who to call next.

Edit with AI Download (.docx + .csv)

Free download · No account needed

What you get

Pack of 9 files: 4 documents, 5 spreadsheets

Incident Escalation Matrix Template

Escalation StandardDocument
Where Severity Thresholds Come FromDocument
Escalation PolicyDocument
After-hours ProcedureDocument
Severity DefinitionsSpreadsheet
Boundary CasesSpreadsheet
Escalation Path by SeveritySpreadsheet
Contact RosterSpreadsheet
Escalation LogSpreadsheet

Incident Escalation Matrix Template

Severity Definitions

Kesterline, field-service software, 6 on the on-call rota

Written from	10 incidents in the 12 months to 31 October
Indexed on	Symptoms visible at minute zero, not impact
Reclassification rate	50%, which is why this is version 3

Each level carries the incidents that landed in it

Level	What the responder can see at minute zero	Real incidents that landed here	If you cannot tell
SEV1	Login, dispatch or card capture failing, not slow. Or writes failing while reads look fine.	14 Mar auth out 51 min. 2 Jun card tokens rejected 22 min. 9 Sep failover stuck 68 min.	Call it SEV1
SEV2	One named feature failing, rest of the product fine. Or one account above 500 seats fully down.	21 Jan invoice PDFs down 4 h. 8 Apr largest account locked out 37 min.	Call it SEV2, say so
SEV3	Visibly wrong, fewer than 50 accounts, and support has a workaround to hand out.	29 May export capped at 1000 rows. 12 Aug crash on one Android version.	No workaround means SEV2
SEV4	One report, nothing broken for anybody else, no revenue path affected.	6 Mar a customer's own firewall blocking our webhooks.	No ambiguity here

Level

What the responder can see at minute zero

Real incidents that landed here

If you cannot tell

SEV1

14 Mar auth out 51 min. 2 Jun card tokens rejected 22 min. 9 Sep failover stuck 68 min.

Call it SEV1

SEV2

One named feature failing, rest of the product fine. Or one account above 500 seats fully down.

21 Jan invoice PDFs down 4 h. 8 Apr largest account locked out 37 min.

Call it SEV2, say so

SEV3

Visibly wrong, fewer than 50 accounts, and support has a workaround to hand out.

29 May export capped at 1000 rows. 12 Aug crash on one Android version.

No workaround means SEV2

SEV4

One report, nothing broken for anybody else, no revenue path affected.

6 Mar a customer's own firewall blocking our webhooks.

No ambiguity here

Why the incidents column is the whole sheet

Nobody woken by a pager compares the thing in front of them against a definition. They ask whether this is as bad as the last bad one. A level carrying three dated precedents answers that; four adjectives do not.

The 9 September entry is the reason SEV1 names a symptom rather than an impact. Reads were healthy, so the dashboard stayed green and it ran as a SEV2 for thirty-one minutes.

Page 1 of 1279 words

How to create an incident escalation matrix

An incident escalation matrix is the table your on-call team checks when something breaks. It says how serious an incident is, who to contact, how fast they must respond and when to bring in someone with more authority. A good one defines each severity level by what a responder can see in the first minute and sets a response time for each. It names a backup for every contact and says what to do when nobody answers.

Write it for the newest person on the rotation, woken at 3 a.m. Every decision should be a lookup, not a judgment call.

A woman on a phone call at her desk late at night, holding a paper coffee cup and looking at an open laptop — When a page goes unanswered, the next step is a phone call. Photo: Vitaly Gariev on Unsplash

Start from the incidents you've had

Don't start with adjectives like critical, major and minor. Pull 6 to 12 months of incidents from tickets, the incident channel, postmortems and status page history. Sort them by how your team really responded: who got woken, how fast someone acknowledged and whether customers were told. The groups that emerge are your real severity levels; where a ticket's label disagrees, trust the response.

Keep two or three dated incidents beside each level, such as "March 14, login failing for every account, 51 minutes." Someone woken at night doesn't compare an alert with a definition. They ask whether this is as bad as the last bad one, and the examples answer that.

Define each level by what responders can see

Definitions built on impact, such as data lost or revenue affected, fail in the first minute, because nobody knows the impact yet. Write each level around symptoms a half-awake responder can check in 30 seconds. What does the alert say? Is a core flow failing, or only slow? Does support have a workaround to give customers?

Use numbers where you can, such as the share of accounts affected, and note what each level is not: slow isn't down. PagerDuty, which sells on-call and incident software, has a simple rule for doubt. If you can't tell a SEV2 from a SEV1, treat it as the higher one¹, then review the call in the postmortem.

Severity levels written as symptoms

Level	What the responder can see	A past incident that landed here	If you can't tell
SEV1	Login, checkout or payments failing, not slow, for over 10% of accounts	Login down for every account, 51 minutes	Call it SEV1
SEV2	One feature failing while the rest works, or one account over 500 seats fully down	Invoice PDFs not generating, 4 hours	Call it SEV2 and say you're unsure
SEV3	Visibly wrong for under 50 accounts, and support has a workaround to give out	CSV export capped at 1,000 rows	No workaround means SEV2
SEV4	One customer's report, and nothing of yours is broken	A customer's own firewall blocking your webhooks	If you're unsure, it isn't SEV4

Illustrative rows for a made-up software company.

Set response times from clocks you can check

Each level needs a target for how fast the person on call responds. Google's Site Reliability Engineering (SRE) book gives typical values of 5 minutes for user-facing or highly time-critical services² and 30 minutes for less time-sensitive systems.

Better still are clocks set outside the company. A customer contract may require you to report an outage within a fixed window, or pay credits below a stated uptime. Build your top levels around those; nobody can argue with them at 2 a.m.

Regulators show what a checkable threshold looks like. In the US, the FCC requires cable, wireless and wireline providers to report any outage of at least 30 minutes that potentially affects at least 900,000 user minutes³. That's users multiplied by minutes, so 30,000 users cut off for 30 minutes would reach it. The first notice is due within 120 minutes of discovering the outage.

Start your own clocks at discovery too. Where no outside clock exists, set each target from your team's real acknowledgment times, at the 90th percentile rather than the average.

Check which deadlines apply to you

Contracts, regulators and data breach laws can set notification deadlines. Ask your lawyer which apply, and give each its own row. Security incidents belong in a security incident response plan.

Escalate when nobody answers, and when nothing moves

Escalation has two triggers, and each needs its own path. No answer means nobody has acknowledged the page. No progress means someone is working on it, but the incident isn't moving. Paging tools can run the first path, so check their settings.

PagerDuty, for example, waits 30 minutes by default⁴ before moving an unacknowledged incident to the next rule. Its own operations team recommends a 5-minute timeout⁵ in the company's public on-call guide, which also tells responders to let PagerDuty's texts and calls bypass Do Not Disturb.

On the no-answer path, phone the person instead of paging again, then page the backup and the manager together. Keep calling up the chain until someone answers.

The no-progress path should add authority at each step, not just more people. First comes someone who can approve a rollback, then someone who can wake anyone or approve customer credits. Decide in advance who can approve what; a RACI matrix is one way to write it down.

Let the clock trigger each step, so nobody has to decide that a colleague is failing. Google's SRE book applies a clock even to declaring an incident: one of the tests it lists is whether the issue is unsolved even after an hour's concentrated analysis⁶.

ExampleA SEV1 escalation path with both triggersAn illustrative example written for this guide.

0 min: The alert pages the primary on call.
5 min, no answer: Phone the primary. Do not send another page.
10 min, no answer: Page the backup and the engineering manager together.
20 min, no answer: Call the head of engineering's mobile from the printed card.
15 min, no progress: The engineering manager joins and can approve a rollback.
30 min, no progress: The head of engineering joins, and the status page goes up.

Two clocks. No answer and no progress run separately, so both can fire in one incident.

Keep a roster that works when your systems don't

Put roles in the matrix and names in a separate roster, so a reorganization changes one sheet. Each roster row needs:

The role and who fills it this week
How to reach them, and how long to wait
Who comes next if they don't answer
A way to reach them without company systems
The date someone last reached them that way

Plan for the outage taking your tools with it. Google's SRE book warns that depending on the software you are trying to fix as part of your incident management system⁶ is unlikely to end well. Print a card with personal mobile numbers and vendor emergency lines, including account numbers.

Give the paging tool and the status page their own rows, each with a fallback, and keep status page updates drafted for each stage of an outage.

Test your escalation matrix against real incidents

After each incident, log two severities: what it was called in the first minutes and what it turned out to be. The share that changed is your reclassification rate, the plainest test of whether your definitions work. For each change, find a similar incident on the other side of the line and write down what truly separated them. That sentence goes into the definition.

Also log escalations that should have fired and didn't, like an engineer who worked an outage alone for 2 hours because a fix felt close. Keep that log blameless. Google's SRE book notes that removing blame from postmortems gives people the confidence to escalate issues without fear⁷.

Review the matrix after every SEV1 and at least quarterly, starting from a postmortem built from the incident data.

Before you share the matrix

Each level names two or three dated past incidents
Each level says what to do if you can't tell
There is a no-answer path and a no-progress path
Every role has a backup and a recent verified date
Key phone numbers are printed somewhere outside your systems

The template on this page has five sheets for this work, from severity definitions to the escalation log, filled in for a made-up company. With Edit with AI, River drafts your severity levels from your own incident history.

How to use this template

Use the files as they are, or open them in River. Every sheet is filled in with a made-up company's incidents and contacts, which shows how the pieces fit before you clear them.

Open it with Edit with AI and send River whatever records you have: a ticket export, an incident channel, postmortems or a spreadsheet someone kept. River sorts past incidents by how your team actually responded and drafts each severity level around them. No history yet? It builds the escalation paths and roster anyway, and the log starts with your next incident.

Download it or open it in River
Download the four Word documents and five CSV sheets free, or open them in River with Edit with AI.
Gather your incident history
Collect 6 to 12 months of tickets, incident channel logs or postmortems, plus the on-call schedule and phone list.
Draft levels and paths
Write severity levels around your past incidents, plus both escalation paths, or ask River to draft them for you.
Share it and log incidents
Give the on-call team the after-hours page, then log what each new incident was called first and what it became.

What's in the template

Line	Incident A	Incident B	What actually separated them	Sentence added
SEV1 / SEV2	14 Mar, nobody could log in	17 Jul, calendar taking 90 s to load	A cannot be waited out. B could, and 80% of users did.	Slow with everything completing is never SEV1
SEV1 / SEV2	2 Jun, all card captures rejected	8 Apr, our largest account locked out	Card capture is contractually SEV1 at any volume. One big account is not, even at 900 seats.	Name the flows that are SEV1 at any volume
SEV2 / SEV3	21 Jan, invoice PDFs down 4 h	29 May, export capped at 1000 rows	No workaround for A. Support could tell B's callers to filter and export twice.	A workaround support can hand out is the line
SEV2 / SEV3	11 Oct, dispatch down for 34 accounts	3 Feb, wrong timezone on job sheets	Both small. A was a core flow with no workaround, B was cosmetic on a non-core flow.	Core flow plus no workaround beats the count
SEV3 / SEV4	12 Aug, crash on one Android version	6 Mar, customer's own firewall	Ours was broken in A. Nothing of ours was broken in B.	A fault entirely on their side is SEV4

Sev	Elapsed	Ladder	Trigger	Action	Authority added
SEV1	0	both	Alert fires or a human declares	Page primary. Open the channel.	none
SEV1	5 min	no answer	Not acknowledged	Call the primary. Do not page again.	none, duplicate first
SEV1	10 min	no answer	Still nothing	Page secondary and manager together	Pull anybody off other work
SEV1	20 min	no answer	Nobody at all	Call the VP on the printed card	Wake anybody in the company
SEV1	15 min	no progress	Acknowledged, no cause	Manager joins. Second engineer arrives unasked.	Rollback, second engineer
SEV1	30 min	no progress	No resolution path	VP joins. Status page up, 30 min cadence.	Credits and external comms
SEV1	30 min	contractual	Card capture affected	Notify the named customer contact	obligation, not a decision
SEV2	15 min	no answer	Owning team silent	Page the product-wide primary	none
SEV2	60 min	no progress	No cause identified	Manager joins and decides if this is a SEV1	Can reclassify upward
SEV3	3 days	no progress	No fix scheduled	Reclassify or accept with a named owner	Owns the decision either way

Role	Channel	No answer in	Then	Works with no company systems	Verified
Primary on-call	Page then voice	5 min	Secondary	Yes, mobile on the card	2 Nov
Secondary on-call	Page then voice	5 min	Engineering manager	Yes, mobile on the card	2 Nov
Engineering manager	Voice call	10 min	VP Engineering	Yes	2 Nov
VP Engineering	Voice call	15 min	CEO	Yes	2 Nov
CEO	Voice call	end of chain	Nothing. Keep calling.	Yes	2 Nov
Database on-call	Vendor line, account number on the card	15 min	Account manager's mobile	Yes, deliberately not in our systems	14 Oct
Named customer contact	Direct line, out-of-hours mobile	contractual	Escalate inside their organisation	Yes, in the printed pack	14 Oct
The paging app itself	Web and mobile	n/a	Voice calls from the printed card	Yes, once the card exists	2 Nov
Status page	Web console	n/a	Second admin with independent credentials	Yes, by design	2 Nov

Date	Incident	Called first	Finally	Ack in	Escalated	Should it have
14 Mar	Auth returning 500s for everybody	SEV1	SEV1	2 min	Yes, 15 min	Yes
9 Sep	Failover stuck, writes down, reads fine	SEV2	SEV1	4 min	Yes, 31 min	Sooner
2 Jun	All card tokens rejected	SEV2	SEV1	3 min	Yes, 9 min	Immediately
17 Jul	Calendar taking 90 seconds to load	SEV1	SEV2	1 min	Yes, 0 min	No, and that is fine
8 Apr	Largest account entirely locked out	SEV2	SEV2	6 min	Yes, 45 min no-answer	Yes
21 Jan	Invoice PDF generation down	SEV2	SEV2	11 min	No, held 3 h 40	Yes at 60 min
11 Oct	Dispatch failing for 34 accounts	SEV3	SEV2	18 min	No	Yes at 60 min
19 Feb	Regional outage, 03:12 onset	SEV1	SEV1	27 min	Yes, 20 min no-answer	Yes
6 Mar	Customer's own firewall blocking us	SEV3	SEV4	40 min	No	No
totals	10 incidents, 12 months	5 reclassified	worst 27 min	2 should have fired and did not

Severity Definitions sheetEach level's visible symptoms, threshold and its source, past incidents, what it isn't and what to do if unsure.
Boundary Cases sheetNear-identical incidents that got different severities, the fact that really separated them, and the rule it added.
Escalation Path by Severity sheetBoth escalation paths in one grid: time elapsed, trigger, action, who acts and the authority they add.
Contact Roster sheetWho fills each role, who's next if they don't answer, an offline way to reach them and a verified date.
Escalation Log sheetEach incident's first and final severity, time to acknowledge, and whether an escalation should have fired.
Escalation PolicyA filled-in sample policy for a made-up software company: scope, severity, both paths, notifications and reviews.
After-hours ProcedureOne page for a half-awake responder: is it a SEV1, who to call and what to do without asking.
Escalation StandardThe four rules behind the matrix, from writing levels around past incidents to running two escalation paths.
Where Severity Thresholds Come FromHow to set thresholds from contract clauses, service credits, regulators and your own response history.

Common questions

What is an escalation matrix?

An escalation matrix is a table that says who handles an incident at each severity level, how fast they must respond and who joins next if they can't. IT, engineering and support teams use one so the person on call never has to decide alone, mid-incident, whether to wake someone.

What should an escalation matrix template include?

An escalation matrix template should include severity levels, a response time for each level, timed escalation steps and a contact list with backups. Define the levels by what a responder can see in the first minute, not by damage you only learn about later, and include a step for when nobody answers.

How many severity levels should you have?

Have as many levels as your team has distinct responses. PagerDuty's public incident guide uses five, from SEV-1 to SEV-5. To count yours, compare who gets woken, how fast someone must respond and whether customers are told. If two levels always get the same response, merge them; if one covers both a night page and a next-day ticket, split it.

What is the difference between functional and hierarchical escalation?

Functional escalation moves an incident to people with more expertise, such as the database team or a vendor's support line; a process map shows which team handles each step. Hierarchical escalation brings in people with more authority, such as a manager who can approve a rollback, customer credits or a public statement. Long incidents often need both, so a good matrix spells out each.

How often should you review an escalation matrix?

Review it after every top-severity incident and at least once a quarter. Check the contact roster more often, by actually reaching each person on the channel listed, and again whenever the on-call schedule, the org chart or someone's phone changes. A matrix pointing to someone who no longer answers fails exactly when it's needed.

Is this incident escalation matrix template free?

Yes. Download the four Word documents and five CSV sheets with no signup. The sheets come filled in for a made-up software company, so you can see how each one works before you swap in your own incidents and contacts. Edit with AI opens the same template in a free River workspace.

What does Edit with AI do?

It opens the template in a free River workspace and asks for four things: your incident history, your on-call records, any outside notification deadlines and who can approve what. River then drafts severity levels around your own past incidents. From there, ask it to build both escalation paths, the roster or the one-page after-hours procedure.

Sources

PagerDuty Incident Response Documentation. “Severity Levels.” response.pagerduty.com (opens in a new tab)
Google SRE. “On Call Engineer Best Practices for IT Services.” sre.google (opens in a new tab)
eCFR. “47 CFR 4.9.” ecfr.gov (opens in a new tab)
PagerDuty Docs. “Escalation Policy Basics.” docs.pagerduty.com (opens in a new tab)
PagerDuty Incident Response Documentation. “Being On-Call.” response.pagerduty.com (opens in a new tab)
Google SRE. “Incident Management: Key to Restore Operations.” sre.google (opens in a new tab)
Google SRE. “Blameless Postmortem for System Resilience.” sre.google (opens in a new tab)

Written by

Chandler Supple

Co-founder & CEO, River

Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.

LinkedIn GitHub X

Reviewed by

Brian Joseff, Co-founder, River

LinkedIn X

Incident Escalation Matrix Template

Kesterline, field-service software, 6 on the on-call rota

Each level carries the incidents that landed in it

Why the incidents column is the whole sheet

How to create an incident escalation matrix

Start from the incidents you've had

Define each level by what responders can see

Set response times from clocks you can check

Escalate when nobody answers, and when nothing moves

Keep a roster that works when your systems don't

Test your escalation matrix against real incidents

How to use this template

Download it or open it in River

Gather your incident history

Draft levels and paths

Share it and log incidents

What's in the template

Boundary Cases

Escalation Path by Severity

Contact Roster

Escalation Log

Common questions

Sources

Chandler Supple

Related tools and templates

More free templates