An incident response runbook is a set of written instructions that tells your team exactly what to do when something goes wrong with a web application. It sits between monitoring, which tells you that a problem exists, and a post-incident review, which examines what happened afterwards. The runbook covers the period in between: the minutes and hours where the right actions reduce damage, and the wrong ones make things worse.

For a business system such as a CRM, a customer portal or an internal workflow tool, an incident is any event that degrades or removes the ability of users to carry out their normal tasks. That includes a complete outage, a partial failure where one feature stops working, a data issue where records appear incorrect or go missing, and a security event such as unauthorised access or a suspected breach. Each of these categories can have its own section within the runbook, or its own separate runbook, depending on the size and complexity of your operation.

The purpose of the runbook is not to replace human judgement. It is to remove the need for people to recall procedures from memory under pressure, to ensure that critical steps like notification and evidence preservation are not skipped, and to give less experienced team members a reliable sequence to follow while a senior engineer investigates the root cause. A runbook that no one can find, or that is so long that no one will read it, provides no value at all.

What belongs in a runbook versus what does not

A runbook should contain actions, not explanations. Each step should tell the reader who does what, which system or tool they use, and what outcome confirms the step is complete. Background information about why the system is built a certain way belongs in architecture documentation, not in the runbook. Similarly, long-term fixes and code changes belong in a separate remediation plan, not in the immediate response steps.

The runbook also should not duplicate your monitoring configuration. If your monitoring system already sends an alert when response times exceed a threshold, the runbook does not need to explain how that alert is generated. It needs to explain what the on-call engineer does after receiving that alert.

Structuring the runbook by incident type

The most practical approach is to organise the runbook by the type of incident, with each section following the same internal structure. A typical structure for one incident type looks like this:

  • Definition and severity criteria. What exactly counts as this type of incident, and how is severity assigned? A clear definition prevents debates at 2 a.m. about whether something qualifies as a P1 or a P2.
  • Immediate triage steps. What does the first responder check within the first five to ten minutes to confirm the incident type and gather initial facts?
  • Communication and escalation. Who gets notified, through which channel, and at what point does the incident commander escalate to a wider group or to senior management?
  • Containment actions. What can be done to stop the problem spreading or affecting more users while the root cause is still unknown? This might include switching to a maintenance page, disabling a specific feature flag, or blocking traffic from a particular source.
  • Diagnostic steps. What logs, metrics, database queries or external service status pages should the investigating engineer check, and in what order?
  • Recovery steps. Once the cause is identified, what is the sequence to restore service? This includes any verification steps to confirm the fix has actually worked before declaring the incident resolved.
  • Evidence preservation. For security incidents in particular, what data needs to be captured and stored before any cleanup or restart actions that might destroy forensic information?

Assigning roles without creating bottlenecks

Every step in the runbook should have a clearly assigned role, not a named individual. People change jobs, go on holiday or leave the company. If the runbook says "Sarah checks the database replication status," it becomes useless the moment Sarah is unavailable. Instead, it should say "the on-call backend engineer checks the database replication status using [specific tool or command]."

For smaller operations where one person may fill multiple roles, the runbook should still distinguish the responsibilities. The same person might act as both incident commander and investigating engineer, but the runbook makes clear which hat they are wearing at each stage. This matters because the incident commander's job is to coordinate, communicate and make decisions about trade-offs, while the investigating engineer's job is to diagnose and fix. When one person tries to do both simultaneously, communication is usually the first thing that suffers.

Writing steps that survive contact with reality

Each step should pass a simple test: could someone who did not write the runbook follow it at 3 a.m. without asking a colleague for clarification? That means avoiding vague instructions such as "investigate the database" and replacing them with specific actions such as "connect to the primary database instance using [tool], run [specific query], and check whether the replication lag value exceeds [threshold]."

Include the actual commands, URLs, dashboard names and tool references. If a step requires logging into a cloud console, state which console, which region and which service. If a step involves checking a third-party service, include the direct link to that service's status page. The extra few minutes spent writing precise instructions save considerably more time during an actual incident.

Keeping the runbook accessible

A runbook stored in a shared drive that requires a VPN to reach is of limited use if the incident involves the VPN itself. Consider where the runbook lives and whether it remains reachable under the exact conditions it describes. For many businesses, a confluence-style wiki that is hosted separately from the production systems, or a static document exported and stored in a second location, provides a practical fallback.

Mistakes that render runbooks useless

The most common failure mode is writing the runbook once and never updating it. Web applications change frequently: new features are added, infrastructure is migrated, third-party integrations are swapped out. A runbook that references a server that was decommissioned three months ago, or a monitoring dashboard that was replaced, actively harms the response by sending engineers down dead ends.

A second frequent mistake is making the runbook too comprehensive. Attempting to document every possible scenario and edge case produces a document so long that no one will read it during an incident. The runbook should cover the most likely and most damaging incidents in enough detail to be actionable. Rare edge cases can be handled with a shorter section that points to the right people and tools rather than prescribing every click.

A third mistake is confusing the runbook with a post-incident review. The runbook tells you what to do. The post-incident review, which happens after the event, examines why the incident occurred and what should change to prevent recurrence. Mixing these two purposes into one document makes both harder to use.

Limitations to understand up front

A runbook cannot cover every incident. Novel failures, combinations of simultaneous issues, or problems in systems you did not know you depended on will always exceed the documented scenarios. The runbook's value in those situations is indirect: because the team has practised following structured procedures for known scenarios, they are better equipped to apply the same discipline to an unfamiliar one.

The runbook also does not replace training. Reading a document is not the same as having worked through the steps in a calm environment. Teams that run tabletop exercises, where they walk through a simulated incident using the runbook without the pressure of a real failure, consistently perform better when an actual incident occurs.

For security incidents specifically, the runbook has a hard boundary. It can cover initial containment and evidence preservation, but detailed forensic investigation, legal notification obligations and regulatory reporting require specialist input that changes as legislation and guidance evolve. The runbook should state clearly at what point the incident is handed to a security specialist or legal adviser, and should not attempt to prescribe actions in areas that require current professional judgement.

Key checks before considering the runbook complete

Before you consider a runbook section finished, run through these checks:

  • Can every step be followed without prior knowledge? If a step assumes the reader knows where something is or how a tool works, add the missing detail.
  • Are severity definitions objective? "The system feels slow" is not a severity criterion. "Average response time exceeds four seconds for more than five minutes" is.
  • Is the escalation path current? Verify that the named roles still exist, the contact channels are correct and the escalation timing is realistic for your team's working patterns, including out-of-hours coverage.
  • Does the runbook account for partial access? If the production environment is unreachable, can the team still access the runbook and the tools it references?
  • Has someone who did not write it tried to follow it? A fresh pair of eyes will find ambiguities and missing assumptions that the author cannot see.
  • Is there a scheduled review date? Attach a review cadence, such as quarterly or after every significant infrastructure change, and assign an owner responsible for keeping it current.

An incident response runbook is not a compliance checkbox. It is an operational tool that either helps your team respond faster and more consistently, or it is shelfware. The difference comes down to specificity, accessibility and regular maintenance. If you are investing in monitoring and alerting for your web application, the runbook is the bridge between knowing there is a problem and knowing what to do about it.