Every team that runs anything in production has an incident runbook. It says who to page, how to declare severity, when to open a status page, who talks to customers, and what has to be true before you call it resolved. It is usually excellent — and it is usually a document that nobody opens while an incident is actually happening.

That is not a discipline problem. Under pressure people work from memory and from whatever is on screen, and a wiki page in another tab is neither. This guide covers how to move the runbook onto the incident itself: the phases it should have, how to gate the order so steps cannot be skipped, how to keep one template across severities, and how the record you need for the postmortem ends up written without anyone writing it.

Why incident runbooks fail at 3am

Incident runbooks fail in three predictable ways, and none of them is about the quality of the runbook.

The first is distance. The procedure lives in a document; the incident lives in a board item, a channel and a dashboard. Every step you take costs a context switch to check whether you took it, so after the second switch people stop checking.

The second is order. Runbooks are sequential for a reason — you do not update the status page before you have confirmed impact, and you do not close an incident before verification. A document cannot stop you doing things out of sequence; it can only describe the sequence and hope.

The third is evidence. When the postmortem asks "when did we page the on-call?" or "who confirmed the rollback was clean?", the answer is reconstructed from chat scrollback days later, by someone who was asleep at the time.

SOP & Compliance Checklists addresses all three by putting the runbook inside the monday.com item that already represents the incident, with owners, gating and a full history — and because everything runs on monday.com's own infrastructure, the incident record never leaves your account.

Model the runbook as a checklist

Open the incident item and its Checklist tab, then map the runbook onto it. The structure that works for almost every team:

  1. Detect & triage — confirm the alert is real, establish blast radius, set severity, name an incident commander.
  2. Communicate — page the right on-call, open the incident channel, post the first internal update, decide whether the status page goes up.
  3. Mitigate — stop the bleeding. Roll back, disable the flag, fail over, scale up.
  4. Verify — confirm the symptom is gone from the outside, not just from the dashboard, and watch long enough to trust it.
  5. Close & hand over — final update, downgrade severity, schedule the postmortem, hand over if the shift is ending.

Each of those is a section, and each step inside it is a task with an owner. The owner matters more here than anywhere else: an unowned step during an incident is a step three people assume someone else took. Where a step has a clock on it — "first customer-facing update within 30 minutes" — give it a due date.

Use task status rather than just a checkbox. A step that is Working on it tells the room something different from one that is Stuck, and Stuck is the signal an incident commander most needs to see. Marking a step stuck fires an automation trigger, so it can raise a notification without anyone having to say it out loud.

An incident runbook modelled as a monday.com checklist with phases and owners
The runbook as a live checklist: phases become sections, each step carries an owner and a status, and the whole thing sits on the incident item.

Gate the order so nobody skips ahead

The sequence in an incident runbook is not stylistic. Publishing a status page before impact is confirmed creates a second incident; declaring resolution before verification means declaring it twice.

Dependencies encode that. A task that depends on an earlier one stays gated until the earlier one is checked, so the list itself surfaces the next actionable step instead of presenting twenty steps of equal weight to someone who is already stressed. "Post public status update" depends on "Confirm customer impact." "Close incident" depends on "Verify from outside." Nobody has to remember the rule, because the list will not let them past it.

Lock the runbook so it survives contact with an incidentOnce the runbook is right, an admin can turn on Lock structure in Settings, so only admins can add, edit, reorder or delete steps. During an incident people improvise — that is what you want from them tactically, and exactly what you do not want happening to the procedure itself. Improvisation belongs in the work, not in the runbook.

A runbook in a document tells you what should happen. A runbook with owners and gated order is the difference between a procedure and a plan you hope somebody remembers.

One template, several severities

Most teams do not need a separate runbook per severity — they need one runbook where the scope of some phases changes. Save the finished checklist as a template and you can apply it to any new incident item in one click, set it as the board default so every incident starts with the runbook already attached, or auto-apply it as items are created. On an incident board, auto-apply is the setting that matters: it means the runbook is present before anyone thinks to attach it.

Where severities genuinely diverge, keep a small number of templates — "Sev1 / customer-facing" and "Sev2 / internal", say — rather than one giant checklist with half its steps marked not-applicable. The guide to checklist templates covers board defaults, auto-apply and bulk-apply in more detail.

Keep the board readable during the incident

Checklist completion can mirror into a board column — a number column for percent, a status column that flips to Done at 100%, or a text column with a readable summary like "7/12 · 58%". During an incident that turns the board itself into a status display: anyone can see how far through the runbook each open incident is without opening it, and your existing monday.com automations can react to that number.

The postmortem writes itself

The most valuable thing a checklist does for incident response happens after the incident ends. Every change is recorded in the audit trail — each status change, assignment, due date and sign-off, with who did it and when. Each task has its own History, and the board-wide History tab streams every incident's activity.

That is your timeline. Not reconstructed from memory, not pieced together from a channel: the actual sequence of what was done and by whom, captured while it happened, because capturing it was the same action as doing the work.

When the postmortem needs something portable, export an audit report (PDF): a completion summary, the sign-off record, the full task table and the complete activity trail, with a SHA-256 document fingerprint that changes if the data changes. If your incident process requires a formal review before an incident is considered properly closed, Compliance sign-off lets a reviewer or approver certify the whole checklist, recording their role, who signed and the completion at signing — and the header flips to an amber Modified after sign-off if anything changes afterwards. The audit trail guide goes deeper on what is captured.

Evidence for your own review, not a certified systemSign-off, the audit trail and the fingerprint are compliance-style controls for internal governance. They are strong internal evidence for a postmortem or an internal audit — they are not a validated, regulator-certified electronic-signature system.

Incident response is the clearest case for putting a procedure on the work rather than beside it: the pressure is highest, the cost of a skipped step is highest, and the need for an honest record afterwards is highest. A runbook that is a checklist on the incident item is followed, in order, by named people — and it hands you the timeline on the way out.