How to write an incident response plan
An incident response plan is the playbook your team follows when something breaks. What to put in one, the phases it should cover, and how to keep it usable.
An incident response plan is the playbook your team follows when something breaks. It is a written, agreed process that says how an incident is detected, how it is classified, who does what, how you keep people informed, and what you do afterwards to stop it happening again. The point is simple: when a service is down, nobody should be inventing the process from scratch.
Good incident response is not about heroics. It is about turning a stressful, high-stakes moment into a set of steps people have seen before. The plan is one part of the wider practice of incident management; this guide walks through what to put in a plan and how to keep it usable, rather than a document that gets written once and never opened.
Why a plan beats improvisation
The middle of an outage is the worst possible time to make decisions. People are stressed, information is incomplete, and every minute has a cost. A plan removes the questions that waste those minutes: who is in charge, how bad is this, who needs to be told, what do we try first.
It also makes incidents consistent. Two different people, on two different nights, should handle a similar failure in a similar way. That consistency is what lets you measure and improve your response over time, and it is what keeps a small problem from becoming a large one because nobody was sure whose job it was.
The phases an incident goes through
Most incident response frameworks describe the same lifecycle. You do not need to adopt a specific standard to benefit from thinking in phases.
- Preparation. Everything you do before an incident: the plan itself, monitoring, on-call rotations, runbooks, and practice. This is the phase with the highest payoff and the one most often neglected.
- Detection and analysis. Noticing that something is wrong and working out what and how bad. Fast, trustworthy detection is what starts the clock in your favour.
- Containment. Limiting the damage while you work, for example failing over, disabling a broken feature, or rolling back a deploy.
- Eradication. Removing the actual cause, not just the symptom.
- Recovery. Restoring normal service and confirming it is genuinely healthy, not just apparently back.
- Post-incident review. Learning from what happened and feeding those lessons back into preparation.
The two bookends, preparation and review, are where lasting improvement lives. The middle phases handle this incident. The bookends make the next one shorter.
What to put in the plan
A plan that tries to cover every scenario becomes a document nobody reads. Aim for a short, practical core that applies to most incidents.
Severity levels
Start with a clear scale for how bad an incident is, because almost everything else keys off it: who gets paged, how fast, and who gets told. Define each level in plain language with a real example. We cover this in detail in incident severity levels explained. Write it down once, and let the plan reference it.
Roles
Under pressure, unassigned work does not get done. Name the roles, not the people, so the plan survives staff changes.
- Incident commander. Owns the response and makes decisions. Crucially, this person coordinates rather than fixes, so someone is always holding the whole picture.
- Technical lead or responders. The people actually diagnosing and fixing.
- Communications lead. Handles internal updates and any customer-facing status, so responders are not interrupted to write updates.
On a small team one person may wear several hats, but the plan should still say which hats exist and who is wearing them for a given incident.
Detection and alerting
The plan should say how an incident reaches a human in the first place. That means automated uptime monitoring that confirms a real failure rather than a network blip, and an alert path that lands where people actually look. Routing alerts into a channel your team lives in, rather than an inbox, is covered in uptime alerts in Slack and Discord. Include how to reach the current on-call and how to escalate if the first responder does not answer.
Communication steps
Decide in advance where the team coordinates during an incident (a dedicated channel or bridge), how often you post internal updates, and what triggers a public status update. A status page is how you tell customers something is wrong without fielding a hundred tickets. Agreeing the thresholds beforehand stops the "should we say something?" debate from happening live.
Runbooks
For the handful of failures you can predict, a runbook turns diagnosis into a checklist: the symptoms, the checks to run, and the safe recovery steps. You will not have a runbook for everything, and that is fine. Write them for your most likely and most damaging failures first.
Keep it usable
A plan is only worth writing if people can follow it at 3am. That means keeping it short, keeping it current, and rehearsing it.
- Short. If the plan is forty pages, nobody opens it during an incident. Fit the core on a page or two, with runbooks linked separately.
- Current. Contact details, on-call rotations and system names go stale fast. Review the plan on a regular cadence and whenever those things change.
- Rehearsed. Run a practice incident, a tabletop exercise or a game day, before a real one tests the plan for you. The first time someone reads their role should not be during an outage.
Close the loop: the post-incident review
When service is restored, the incident is not finished. A blameless post-incident review asks what happened, what the timeline was, what went well, and what to change, without hunting for someone to blame. The goal is systems and process fixes, not fault.
This is also where your metrics come from. Tracking mean time to recovery across incidents tells you whether your response is actually getting faster, and pinpoints the phase where time is being lost. Every review should produce a small number of concrete actions that feed back into the preparation phase, so the plan gets a little better each time.
Getting started
You do not need a heavy framework to begin. Write down your severity levels, name the roles, document how alerts reach the on-call, agree your communication thresholds, add a runbook or two, and include a review template. Then rehearse it once. That short, practised plan will serve you better than an exhaustive one nobody has read.
The foundation of all of it is knowing about incidents quickly and reliably. Start monitoring free, no credit card, so your plan is triggered by a confirmed alert the moment something breaks, not by a customer email an hour later.
Frequently asked questions
- What is an incident response plan?
- An incident response plan is a documented, agreed process your team follows when a service breaks or is attacked. It defines how incidents are detected and reported, how they are classified by severity, who does what, how you communicate, and what happens after, so people follow a rehearsed plan instead of improvising under pressure.
- What are the phases of incident response?
- A common model has six phases: preparation, detection and analysis, containment, eradication, recovery, and a post-incident review. Preparation and the review are the ones teams most often skip, and they are where most of the long-term improvement comes from.
- What should an incident response plan include?
- At a minimum: severity definitions, clear roles such as incident commander and communications lead, how people are alerted and how to reach the on-call, communication steps for internal and external updates, a few runbooks for the most likely failures, and a template for the post-incident review. Keep it short enough that people actually read it.
- How often should you update an incident response plan?
- Review it after every significant incident, since real incidents expose gaps faster than anything else, and on a regular cadence such as quarterly. Also update it whenever roles, on-call rotations, or critical systems change, so the contact details and steps never go stale.