Runbook vs Playbook: Differences, Templates and a Worked Example

What's in this guide

• What a runbook is, what a playbook is, and the differences that actually matter
• Where SOPs fit, since somebody always asks
• A copy-paste runbook template and playbook template
• A filled-in runbook, so you can see one completed rather than blank
• A worked SEV1, minute by minute, showing both documents in use
• What to automate, what auditors want, and how to stop both documents rotting

At some point in every incident, somebody types the sentence that gives the whole thing away: "wait, is there a doc for this?"

There usually is. It's just that nobody can find it, or the one they find was written against an architecture that got replaced in March, or it's forty pages long and the useful part is on page twenty-eight. Underneath that mess is almost always the same structural problem: the team wrote one document where they needed two.

Runbooks and playbooks solve genuinely different problems. Collapse them into a single doc and you get something too long to follow at 3 a.m. and too tactical to hand to a stakeholder. Keep them separate and each one gets short, useful, and much easier to keep honest.

What is a runbook?

A runbook is a procedure for one failure mode, written for the one person with their hands on the keyboard. It names the symptom that sends you there, the read-only commands that tell you what's happening, the fix, how to know the fix worked, and what to do when it doesn't.

The defining constraint is that a runbook is read under pressure by someone who may have been asleep four minutes ago. That rules out background, context, architecture diagrams and anything else that would be interesting on a Tuesday afternoon. If a line doesn't help the responder decide or act in the next sixty seconds, it belongs somewhere else.

Runbooks are also the half of the pair that goes stale fastest, because they're coupled to infrastructure. Every deploy is a small chance that one of your runbooks is now lying to you.

What is a playbook?

A playbook covers a whole class of event (a customer-facing outage, a security breach, a failed migration), and it's written for everyone in the channel who isn't fixing it. It sets the severity scale, names the roles, fixes who talks to customers and when, and marks the decisions someone has to make explicitly: roll back or fix forward, go public or hold, wake the second team or leave them asleep.

The audience test is the cleanest way to tell the two apart. A runbook is for the keyboard. A playbook is for the incident commander deciding sequencing, the comms lead drafting a status update, the manager working out whether to pull someone off another team.

Which is also why a playbook outlives a re-platforming and a runbook usually doesn't. Your org chart changes slowly. Your infrastructure changes every Thursday. And both are only useful if they reach the responder while it matters, which is the argument for keeping them attached to the service inside your incident management platform rather than in a wiki nobody can search one-handed at 2 a.m.

Runbook vs playbook: the differences that matter

The line that does the most work in practice: a playbook should not contain a single command. The minute it does, it has quietly become a runbook, and it starts rotting at the speed of your infrastructure instead of the speed of your org chart.

And the relationship runs one way. Playbooks link to runbooks. A playbook's "linked runbooks" table is its most valuable section and the one most teams forget to fill in.

Which should you build first?

Build the runbook first, in almost every case. Runbooks come out of failures you've already had, so the raw material is sitting in your incident history rather than in a planning session, and each one starts paying you back the first time somebody opens it at 3 a.m.

The exception is a team where more than one group already responds to the same incident. If your problem is four people all investigating the same symptom while nobody talks to the customer, no runbook fixes that: coordination is the bottleneck, and you need the playbook first.

A reasonable first month: one playbook for your worst-case category, and one runbook for each of the three alerts that fire most often. That's four documents, and it covers a surprising share of what actually wakes people up.

Where does an SOP fit?

Sooner or later somebody asks whether this is all just an SOP with extra steps. Fair question. A standard operating procedure is the wider category the other two live inside: any documented, repeatable way of doing a thing, incident or not. Onboarding a new hire is an SOP. Closing the books is an SOP. Neither is a runbook.

What separates them is urgency and audience. An SOP is read in calm conditions by whoever owns the process. A runbook is read mid-incident by one person. A playbook is read mid-incident by everyone else.

If you already keep SOPs, you're not starting from zero. Most teams with a compliance function have a folder of them, and the incident-shaped ones are runbooks and playbooks wearing a different label. Splitting that folder in two, commands here and coordination there, is usually faster than writing anything new.

Runbook template (copy-paste)

Budget about twenty minutes for your first one, and less for every one after. Replace anything in angle brackets, delete any section that doesn't apply, and don't be precious. A template you've argued with is worth ten you filled in politely.

# Runbook: <Failure mode> on <Service>

Owner: <team>
Last reviewed: <YYYY-MM-DD> by <name>
Applies when: <the exact alert name or symptom that sent someone here>
Expected duration: <minutes>
Risk: <safe to run alone | needs a second pair of eyes | needs approval>

## 1. Confirm you are in the right runbook
- [ ] Symptom matches: <observable signal, e.g. p99 > 2s on /checkout for 5 min>
- [ ] Dashboard: <link>
- [ ] If the symptom does not match, stop. Go to <other runbook>.

## 2. Gather state (read-only, safe to run)
<command>            # what this tells you
<command>            # what this tells you
Paste the output into the incident thread before you change anything.

## 3. Fix
| # | Action | Expected result | If it fails |
|---|--------|-----------------|-------------|
| 1 | <command or click-path> | <what you should see> | go to step 5 |
| 2 | <command or click-path> | <what you should see> | go to step 5 |

## 4. Verify
- [ ] <metric> below <threshold> for <n> consecutive minutes
- [ ] No new errors in <log source>
- [ ] <downstream service> healthy

## 5. If this did not work
Escalate to <role / rotation>. Do not repeat step 3 more than twice.
Say in the thread: what you ran, what you saw, what you expected to see.

## 6. Rollback
<the exact steps to undo everything in step 3, in reverse order>

## 7. Clean up
- [ ] Revert temporary changes: <list>
- [ ] Write down whatever made this runbook wrong, before you forget it

Two lines carry most of the weight. Applies when is what makes the runbook findable by someone whose brain is running at thirty percent. Quote the alert text, don't describe it. And If it fails is the line that stops a tired engineer running step 3 for the fifth time, because nobody ever told them what else they were allowed to do.

A filled-in runbook

Blank templates are easy to agree with and hard to copy. Here is the same skeleton completed, for the checkout latency alert used in the worked example further down.

# Runbook: Latency spike on Checkout API

Owner: Payments
Last reviewed: 2026-08-24 by M. Beller
Applies when: alert `p99_latency_checkout > 2s` fires
Expected duration: 10–15 minutes
Risk: steps 1–2 safe to run alone; step 6 needs a second pair of eyes

## 1. Confirm you are in the right runbook
- [ ] Symptom matches: p99 on POST /checkout above 2s for 5 consecutive minutes
- [ ] Dashboard: grafana.internal/d/checkout-api
- [ ] If 5xx are elevated but latency is normal, stop.
      Go to Runbook: Elevated 5xx on Checkout API.

## 2. Gather state (read-only, safe to run)
kubectl -n payments get pods -l app=checkout      # anything not Running/Ready?
kubectl -n payments logs -l app=checkout --since=15m | grep -i "pool\|timeout"
psql -c "select state, count(*) from pg_stat_activity group by 1;"   # queue depth
Paste the output into the incident thread before you change anything.

## 3. Fix
| # | Action | Expected result | If it fails |
|---|--------|-----------------|-------------|
| 1 | kubectl -n payments rollout restart deploy/checkout | p99 under 2s within 2 min | go to step 5 |
| 2 | Cap concurrency: set CHECKOUT_MAX_CONN=40 | queue depth falling within 3 min | go to step 5 |

## 4. Verify
- [ ] p99 below 2s for 10 consecutive minutes
- [ ] No new "pool timeout" lines in the checkout logs
- [ ] payments-worker healthy

## 5. If this did not work
Escalate to the database rotation. Do not repeat step 3 more than twice.
Say in the thread: what you ran, what you saw, what you expected to see.
Note: in the last three occurrences the cause was a missing index shipped
in a deploy. Check the last 24h of migrations early.

## 6. Rollback
Reset CHECKOUT_MAX_CONN to 100, then:
kubectl -n payments rollout undo deploy/checkout

## 7. Clean up
- [ ] Reset CHECKOUT_MAX_CONN if it was changed
- [ ] Write down whatever made this runbook wrong, before you forget it

Look at the note in step 5. That line is three incidents' worth of institutional memory, written down in one sentence, and it is the single highest-value thing in the document. It's the difference between the database on-call starting from scratch and starting from a hypothesis. Good runbooks accumulate those. Great ones get them near the top.

Playbook template (copy-paste)

This one takes longer to agree on than to write. Budget an hour with the people whose names go in the roles table, and fifteen minutes of actual typing.

# Playbook: <Event category, e.g. customer-facing outage>

Owner: <team>
Last reviewed: <YYYY-MM-DD> by <name>
Trigger: <what puts this playbook into effect>
Does not cover: <adjacent categories, and which playbook does cover them>

## 1. Severity
| Severity | Definition | Response |
|----------|------------|----------|
| SEV1 | <customer-visible, revenue-affecting> | page immediately, all roles staffed |
| SEV2 | <degraded, workaround exists> | page primary on-call, IC optional |
| SEV3 | <internal only> | ticket, business hours |

## 2. Roles
| Role | Who | Owns | First action |
|------|-----|------|--------------|
| Incident Commander | <rotation> | decisions and sequencing, not fixing | open the channel, state severity |
| Operations lead | <team> | the technical fix, runs the runbooks | claim the symptom, name the runbook |
| Communications lead | <role> | internal + external updates | post first update within <n> min |
| Scribe | <role> | the timeline | timestamp every decision |

## 3. Timeline
| When | What happens | Who |
|------|--------------|-----|
| 0–5 min | Declare, set severity, assign IC | first responder |
| 5–15 min | Roles staffed, symptom named, runbook opened | IC |
| every <n> min | Stakeholder update, even if nothing has changed | comms lead |
| on mitigation | Announce that mitigated is not resolved | IC |

## 4. Decision points
- Roll back or fix forward? Default: <your default>. Called by: <role>.
- When does the public status page go up? Threshold: <condition>.
- When do we wake a second team? Threshold: <condition>.
- Who is allowed to approve <destructive action>?

## 5. Linked runbooks
| Symptom | Runbook |
|---------|---------|
| <symptom> | <link> |
| <symptom> | <link> |

## 6. Communication templates
Internal, first message:
"<Severity> on <service>. Impact: <what customers see>. IC: <name>.
Next update at <time>."

External, holding statement:
"We are investigating <symptom> affecting <feature>. Next update in <n> minutes."

## 7. Exit criteria
- [ ] <metric> stable for <n> minutes
- [ ] Customer impact confirmed ended
- [ ] IC declares resolved in the channel

## 8. After
- [ ] Post-mortem scheduled within <48h>
- [ ] Timeline exported from the incident channel
- [ ] Runbooks corrected while it is all still fresh

Notice what isn't in there: a command, anywhere. That's the test.

A worked example: one SEV1, both documents

02:14. p99_latency_checkout > 2s fires and somebody's phone lights up on the nightstand.

The playbook goes first. Customer-visible and revenue-affecting, so it's a SEV1. That's the severity table doing its job, not a judgement call made at 02:15 by someone who has been awake for ninety seconds. The responder declares it, opens the channel and holds incident commander until someone more senior wanders in. Comms lead posts a holding statement at 02:19. Nobody has typed a command yet, and that's deliberate: the playbook's entire contribution so far is answering who is doing what, and by when.

Then the runbook takes over. The alert text matches the "Applies when" line on Runbook: Latency spike on Checkout API, the one printed in full above. Step 2 is read-only and safe: connection pool pinned at 100%, query queue climbing, one slow query eating everything. Step 3, action 1 recycles the pool. Expected result was p99 recovering inside two minutes. It doesn't. And because the "If it fails" column says go to step 5, at 02:31 the ops lead escalates to the database rotation instead of doing the thing everyone does at 2 a.m., which is trying it again slightly harder.

The note in step 5 saves twenty minutes. Check the last 24h of migrations early. The database on-call starts there rather than at the top, and finds a missing index that shipped in the evening deploy.

They close it out together. Rollback, per step 6 of the runbook. p99 back under threshold by 02:44, held for ten minutes, and the exit criteria in section 7 of the playbook are what let the IC actually declare it resolved at 02:56, rather than everyone drifting off to bed unsure whether it was over. The post-mortem is on the calendar before anyone logs off.

The split holds the whole way through: the playbook decided this was a SEV1 and who would run it, the runbook decided what to type. Neither could have covered for the other. Merge them into one document and your responder is reading org-chart prose at 02:16 while the queue grows.

Which metric each document moves

Worth being precise about this, because the two documents are usually justified with the same hand-wave and they do not do the same job.

Runbooks move MTTR. They compress the repair itself: less time deciding what to run, fewer wrong turns, no re-deriving a fix somebody already worked out in March.

Playbooks move the coordination clock: time to declare, time to the right people being in the room, time to first stakeholder update. Those rarely appear on a dashboard, which is exactly why playbooks are the easier of the two to skip and the more painful to be missing.

One honest caveat: neither moves MTTA. Time-to-acknowledge is a paging and routing problem: who got woken, on what channel, and whether the escalation fired. No document fixes that. If your MTTA is bad, the fix is in your alerting configuration, not your wiki.

Runbook automation: what can and can't be scripted

The reason this distinction matters commercially, and not just semantically, is automation. A runbook made of deterministic commands is a script that hasn't been written yet, and every step you promote from "engineer types this" to "the system already did this" comes straight off MTTR, off the part that's pure latency: a human waking up and copying a command they've copied forty times before.

A sensible order to automate in:

• Diagnostics first. Step 2 of the runbook template, the read-only gathering, is the safest thing on the page and often the slowest. Attach that output to the alert and your responder opens their laptop to a diagnosis instead of a blank prompt.
• Then reversible fixes. Recycling a pool, clearing a cache, scaling a group up. Things where the worst case is that nothing improves.
• Then irreversible ones, cautiously, and only behind an explicit human approval step, which is precisely the kind of gate a playbook exists to define.
• Never the judgement. Whether this is a SEV1, whether to go public, whether to wake the database team at 02:31. That stays human, and it stays in the playbook.

One failure mode worth naming: automating a runbook does not delete it. Somebody still has to know what the automation does when it half-works at 3 a.m., and an automated step with no written record of its intent is worse than a manual one. Keep the runbook, mark the automated steps, and write down what to do when they don't fire.

What auditors actually want

If you work somewhere with a compliance function, these two documents are already on somebody's evidence list, and it's worth knowing which questions they answer.

ISO 27001 expects that incident response is planned rather than improvised, that someone assesses and classifies events, that response follows documented procedures, that lessons feed back in, and that evidence is collected along the way (ISO/IEC 27001:2022, Annex A 5.24–5.28). Read that list again and it maps almost one-to-one onto a playbook: severity definitions, named roles, a decision trail, a post-mortem commitment. SOC 2 asks a narrower question, that you evaluate events and respond to them consistently (CC7.3–CC7.4), and consistency is what a written procedure is for.

The practical translation: the playbook is your evidence of process, and the runbooks are your evidence of execution. An auditor asking "show me how you handle a customer-facing outage" wants the playbook. One asking "show me you actually did that on 14 March" wants the incident timeline and the runbook it references.

Two things earn credit disproportionately, and both are free: a review date and an owner on every document, and timestamps that survive the incident, meaning a channel export rather than somebody's memory. All Quiet keeps that timeline automatically, and if compliance is the driver you may also want our notes on ISO 27001 and SOC 2.

Keeping both documents alive

Documentation dies quietly, so the maintenance rules matter more than the writing rules:

• Fix the runbook during the incident, not after. The person who just found it wrong is the only person who will ever remember exactly how. Ten seconds in the thread beats a ticket nobody grooms.
• Version them with the code they describe. A runbook in Git gets reviewed when the service changes. A runbook in a wiki gets reviewed never.
• Give every document an owner and a review date, and let both go stale visibly. A runbook last reviewed in 2024 should look alarming.
• Run one tabletop a quarter. Not a full game day: one hour, one scenario, follow the playbook literally and note every place it fails to answer a question.
• Delete aggressively. Two half-accurate runbooks for the same failure are worse than one accurate one, because at 3 a.m. somebody will open the wrong one.

Getting the right document to the right person

None of this helps if the document doesn't arrive with the alert. That's the gap most teams still bridge manually: an engineer gets paged, opens a laptop, and starts searching a wiki for the thing that should have arrived alongside the page.

All Quiet closes it by attaching runbooks to incidents automatically, mapping payload fields to the right document so the link lands in the Slack thread with the alert itself. Your playbook defines who shows up; your on-call schedule decides who gets woken; and the runbook is already open by the time they are.

Start a free 14-day trial →