Free templateIncident response runbook
When the site goes down
An incident runbook page: six moves and who makes them, with the first hour drawn as a clock face.
Free. It opens in the Motionix editor as your own copy.
Download the pictureWebP, 1200 × 675, free to use. To change the words or colours, open it in the editor.
- Size
- 1920 × 1080 px
- Pages
- 1
- Motion
- Yes, plays live and in GIF or video
- Category
- Processes
What it shows
- A clock that fills in
- Roles beside every step
- Status updates on a timer
Good for
How to use it
- Open the template. It becomes a project in your account.
- Change the words, colours and pictures. Every part is an ordinary shape, line or text box.
- Press Play to watch it build, then present it or export it.
What is an incident response runbook?
An incident response runbook is a written plan for what to do, and who does it, when a service fails or a security incident is detected. It sets out the steps in order, such as detect, declare, mitigate, communicate, resolve and review, with the roles responsible and the timings to keep, so the team acts calmly instead of improvising under pressure.
When it helps
- An engineering team agreeing what happens in the first hour when the website goes down.
- Briefing new on-call engineers before their first rotation.
- Practising a simulated outage, sometimes called a game day, against a written plan.
- Showing customers or auditors that outages are handled by a defined process.
Tips
- Keep the runbook short enough to read during an incident. Detailed technical fixes belong in linked documents; the runbook is about who does what and when.
- Practise it before you need it. A runbook nobody has rehearsed fails on small things, like nobody knowing who holds the status page login.
- Make the incident lead someone who is not typing the fix. Coordination and debugging both need full attention, and doing both slows each down.
How to write an incident response runbook
Define severity levels
Agree what counts as a severity one, two and three incident, with clear examples such as the whole site down or one feature slow. Severity decides who is woken and how fast.
Name the roles
Assign an incident lead who coordinates, engineers who fix, and a communications lead who updates customers and staff. One person should not try to do all three.
Order the moves
Write the steps in the order they happen: acknowledge the alert, declare the incident, open a channel, mitigate, communicate, confirm recovery and review. Give each a target time.
Put mitigation before diagnosis
Tell the team to stop the harm first, by rolling back, failing over or switching a feature off, and to find the root cause once customers are no longer affected.
Set the update rhythm
Fix when the first status update goes out and how often updates follow, even if there is nothing new. Silence worries customers more than an update saying work continues.
End with a review
Require a blameless post-incident review within a few days: what happened, why, how it was detected and what will change. Record the actions and who owns them.
FAQQuestions
Common questions.
What are the phases of incident response?
Frameworks name them differently, but most include preparation, detection, containment or mitigation, recovery and a post-incident review. A widely taught model from NIST groups them as preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Operations teams often add declaring the incident and communication as explicit steps.
What is the difference between a runbook and a playbook?
The terms overlap and teams use them differently. Commonly, a runbook gives step-by-step instructions for a specific task or failure, such as restarting a service, while a playbook describes the wider response to a type of situation, including roles, communication and decisions. An incident runbook often sits between the two.
What is a blameless postmortem?
A blameless postmortem is a review after an incident that focuses on how the system and process allowed the failure, not on who made a mistake. Because people are not punished for honesty, they share what really happened, and the team fixes underlying causes instead of hiding them.
More processes templates
Flowcharts, procedures and step-by-step journeys.
