Escalation path diagrams for on-call runbooks

An incident at two in the morning is a bad time to read a paragraph. The engineer who has just been woken needs to know three things quickly: how serious is this, who do I tell, and what happens if nobody answers. A written escalation policy usually contains all three, spread across several sections and a table of phone numbers.

An escalation path diagram puts that policy into one picture. It sits at the top of the runbook, above the detailed steps, and answers the question “who is next?” at a glance. This article covers what to include, how to lay it out and how to keep it accurate.

What the diagram needs to show

An escalation diagram is a flowchart with two extra concerns: time and severity. A useful one shows:

• The trigger. An alert fires, a customer reports an outage, or a monitoring check fails.
• The severity decision. How the first responder classifies the incident.
• Who is contacted at each level. By role, not by name.
• Time limits. How long each person has to acknowledge before the next one is contacted.
• The end states. Resolved, handed to a specialist team, or declared a major incident.

Leave out the diagnosis steps. “Check the database connection pool” belongs in the runbook’s troubleshooting section. The escalation diagram is about people and time, not about fixing the fault.

Start with the severity decision

Most escalation policies split incidents into levels. Draw the classification as the first decision after the trigger, with one exit per level.

Level	Typical meaning	First contact
Sev 1	Service down for many users	Primary on-call and incident lead together
Sev 2	Major feature broken or degraded	Primary on-call
Sev 3	Minor issue with a workaround	Team queue, next working day

The levels and their definitions are your team’s to set; the table above is an example only. Write the definitions beside the diagram or in a short key, because “major” means different things to different people at night.

Each severity becomes its own path. Sev 3 often ends almost immediately (“Log ticket for the team queue”). Sev 1 and Sev 2 carry the escalation chain.

Draw the escalation chain with time

For each serious path, draw the sequence of contacts as steps, with a decision after each. For example:

1. Page primary on-call.
2. Acknowledged within 10 minutes? Yes: primary owns the incident. No: page secondary on-call.
3. Acknowledged within 10 minutes? Yes: secondary owns it. No: page the engineering manager.

The time limit belongs in the decision label, not in a note elsewhere. “Acknowledged within 10 minutes?” is unambiguous. “Acknowledged?” leaves the reader to guess when to move on.

Put the timings your policy actually uses. If the policy does not state them, drawing the diagram is a good moment to agree them.

Use lanes for roles

When several roles are involved, a swimlane layout makes the chain easy to follow. Typical lanes:

• Monitoring or alerting system
• Primary on-call
• Secondary on-call
• Incident lead or engineering manager
• Specialist team, such as database or networking
• Communications, for customer or status-page updates

Each contact is an arrow crossing into the next lane. The crossings are where incidents stall, so seeing them clearly is the point. Swimlane diagrams explained covers the layout in more detail.

Label lanes by role and keep the rota, the actual names and numbers, in a separate, frequently updated place. A diagram with names on it is out of date the week the rota changes.

Show the handoff to specialists

Many incidents move from the on-call engineer to a specialist team. Draw this as a decision (“Needs database team?”) and an arrow into that team’s lane, with what the handoff includes:

• the incident ticket or channel
• what has been tried
• current impact

The note can be short. A page saying only “DB issue, please help” leaves the specialist starting with questions.

Mark the major-incident branch

For the most serious cases, most teams switch to a different mode: an incident lead takes charge, a communications role starts updating customers, and regular check-ins begin. Show the trigger for this switch as its own decision, for example “Customer-facing outage over 30 minutes?”, and route it to a single box that refers to the major-incident procedure.

One box marked as a separate process keeps this diagram readable; the major-incident procedure deserves its own chart.

Layout habits for night-time reading

The diagram will be read on a phone, under stress, by someone who may be new to the rota.

• Main path down the centre. The most common route, usually Sev 2 with a prompt acknowledgement, should be the straightest line.
• Large labels. Three to six words per box. Time limits in the labels.
• One accent colour for the decision that matters most, usually severity.
• No crossing lines. If arrows cross, move the lanes.
• Every path ends. “Incident closed”, “Handed to database team”, “Major incident declared”.

Test it with a tabletop exercise

Before publishing, walk through two or three scenarios with the team using only the diagram. For example, a Sev 2 alert at night where the primary doesn’t respond, or a Sev 1 that turns out to need the networking team.

Typical findings: a time limit nobody agreed, a role that is on the diagram but not on any rota, or a step that the team skips in practice. Fix the written policy at the same time as the diagram, as you would for any SOP flowchart.

Keep it next to the runbook

Store the diagram at the top of the runbook it belongs to, with an owner and a review date. Review it whenever the rota structure, severity definitions or specialist teams change. If the policy is already written down step by step, that text is a good description to work from in DiagramsPro or any other diagram tool.