Incident escalation protocol
Steps from detection through alert routing, assignment, and escalation.
Every organization has incidents — services fail, data goes stale, customers can't log in. But many teams discover during an outage that nobody has agreed on who to page, when to escalate, or when an incident is officially resolved. This template maps the journey from the moment an alert fires to ownership, mitigation, and the postmortem.
The severity diamond is the key decision: Critical incidents page the on-call engineer immediately, High creates an urgent ticket, and Medium goes to the backlog. The flowchart then tracks the escalation: if the on-call engineer doesn't acknowledge within the SLA, the manager is paged. This prevents the scenario where an incident sits unresolved because everyone thought someone else was working it.
When to use this template
- Incident response plan review — walk the team through how a real critical incident should flow. Are the escalation targets right? Are the timeouts realistic?
- On-call handoff — when a new engineer joins the on-call rotation, show them this diagram so they see what "Critical" actually means and what happens if they don't respond.
- Postmortem incident analysis — after an incident, trace which path it took in this diagram. Did it escalate correctly, or did something fall through?
How to adapt it
Start by defining your severity levels clearly — Critical means revenue-impacting production outage, High means degraded service or data freshness, Medium means technical debt or small bugs:
- Add a triage step between Alert and Severity: does it need manual confirmation before paging, or is it automatic?
- Insert a war room creation decision after High or Critical — some teams start a Slack channel and invite stakeholders for visibility.
- Replace the static timeouts (30 min) with your actual SLAs — look at historical incidents and set realistic escalation windows.
Visual edits regenerate clean code, so you can refine this diagram as your incident practices evolve.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Alert triggered] --> B{Severity level?}
B -->|Critical| C[Page on-call engineer]
B -->|High| D[Create urgent ticket]
B -->|Medium| E[Add to backlog]
C --> F{Response within SLA?}
D --> F
F -->|No| G[Escalate to manager]
F -->|Yes| H[Acknowledge incident]
G --> I[Manager pages backup]
I --> H
H --> J[Begin mitigation]
J --> K{Resolved?}
K -->|No| L[After 30 min, escalate team lead]
K -->|Yes| M[Post-incident review]
L --> M
Frequently asked questions
- What is an incident escalation protocol?
- It maps how alerts move through your organization when a problem is detected: which severity level triggers which response, who gets paged first, when to escalate to a manager, and how long each step has to respond before the next level is triggered. It ensures critical issues don't slip through the cracks and that every incident has a clear owner and timeline.
- Why does this diagram have time-based escalation (30 min timeout)?
- Because without explicit timeouts, an incident can sit unresolved while everyone assumes someone else is fixing it. Time-based escalation forces the handoff: if the on-call engineer doesn't resolve it in 30 minutes, the team lead joins automatically. This prevents long outages from unclear ownership.
- How do I customize this for my organization?
- Start by replacing the severity levels with your own (e.g., S1, S2, S3 or Critical/Major/Minor). Change the escalation targets — on-call engineer, manager, team lead — to match your roles. Adjust the timeouts (the 30-min example) to match your SLAs. Visual edits regenerate clean Mermaid code, so you can sketch these changes in the editor without writing syntax.
- Should this diagram include postmortems?
- Yes. The 'Post-incident review' node at the end forces a debrief for every incident above a threshold. For critical incidents, add a mandatory postmortem deadline (e.g., within 24 hours) and a blameless review meeting. This diagram should be a contract between the team and leadership about how incidents are handled end-to-end.