Runbook vs playbook vs MOP

Published 22 September 2026

The three words get used as synonyms and they describe three different documents. A runbook is a recurring operation. A playbook is a class of incident. A method of procedure is a one-time change. Mixing them up is why change approvals bounce, and why the wrong document ends up attached to the ticket.

The distinction in one table

Everything below is an elaboration of this. If you only read one thing, read the last row.

	Runbook	Playbook	MOP
Covers	A recurring task	A class of incident	One specific change
Run how often	Many times, unchanged	Whenever that symptom appears	Once
Shape	A fixed sequence	Branches and decision points	A fixed sequence, plus a way back
Written before	The task becomes routine	The incident happens	The window opens
Outcome known?	Yes	No: that is the point	Yes, and verified explicitly
Has a rollback and a named approver	No	No	Yes: this is the difference

A runbook is a recurring operation

Restart the batch job. Rotate the certificate. Fail the database over to the secondary and back. Add a site to the monitoring system. The defining property is that the steps are the same every time, because the situation is the same every time.

That makes the audience the real test. A runbook is written so that someone who is not you can do it at 3am, having never done it before, without phoning you. If a step says "check the config looks right", it is not a runbook step: it assumes the knowledge the document exists to replace.

So a runbook contains: preconditions, the exact commands, the expected output of each, and what to do if it does not appear: usually "stop and escalate to X", not a diagnostic tree. A runbook growing diagnostic branches is telling you it wants to be a playbook.

In ITIL 4 terms a runbook underwrites a standard change: low risk, well understood, pre-authorised, executed against a documented procedure. Nobody approves it individually because the procedure was approved once, in advance. That is the economic argument for writing one.

A playbook is a class of incident

"The API is returning 5xx." "Latency is up and nobody deployed." "A site dropped off the monitoring map." You do not know the cause, and therefore you do not know the path. A playbook is a decision tree with the diagnostic questions already worked out: if X, check Y; if Y is clean, it is not the network, go look at Z.

The value is not in telling an engineer what to type. It is in front-loading the thinking that is hard to do well at 4am, which signal distinguishes two plausible causes, which check is cheap and conclusive, which one only looks conclusive. Google's Site Reliability Engineering (2016) puts the effect of having one at roughly a threefold improvement in mean time to repair over improvising: one organisation's number, but the direction is not controversial.

A good playbook therefore contains: the symptom as it actually appears in the alert, the two or three causes worth ruling out first and how to rule each one out, the mitigations available before root cause is known, and the escalation path with names on it. It does not contain a single ordered list of steps, because there is no single order.

A playbook should link to runbooks. "If it is the cache tier, run the cache flush runbook" is exactly right: the branch belongs in the playbook, the fixed procedure in the runbook.

Vulnerability response is the same shape. Whether a finding becomes an emergency depends on affected version, exposure and evidence of active exploitation; KEV vs CVE turns those inputs into the branches of a defensible patch-priority playbook.

What is a MOP, and what it has that the others do not

A method of procedure (MOP) is the document for a change that happens once, usually inside a maintenance window, usually with a service impact. Replace the core switch. Cut the building over to the new firewall pair. Migrate the VLAN to the new spine. It is carrier and data centre vocabulary; the MOP network and facilities teams use is the same document, and only the steps differ.

In ITIL terms this is a normal change: assessed and authorised individually because it has not been done before and will not be done again in this form. The MOP is what gets assessed. That is why it carries four things a runbook and a playbook have no reason to carry.

A back-out plan. Not "restore from backup": the actual steps, with an expected duration, because the duration is what determines whether you can afford to start. There's a backout plan template with a worked example.
A back-out decision time. A clock time, agreed in advance, at which you stop trying to finish and start reverting.
A named approver. A person, not a queue. Technical approval and business approval are often two different signatures.
A verification step. A specific, checkable statement of what "it worked" means. Not "confirm service restored".

The verification step is the one people skip and the one that pays. Without it the window ends when the steps run out, which is not the same event as the change succeeding. Changes discovered to have failed on Monday morning were usually declared complete on Saturday night by someone reaching the bottom of a step list.

The back-out decision time is the single most useful line in a MOP. Windows do not overrun because the rollback was impossible. They overrun because at 03:40, twenty minutes from the end of a window, the person at the console is ten minutes from finishing and reasonably believes it. A time agreed while nobody was tired removes that judgement call from the worst possible moment to make it.

What breaks when you use the wrong one

These are not stylistic complaints. Each has a distinct failure mode.

A runbook used for an incident sends people down a path that does not fit. A fixed sequence written for one cause, applied to a symptom with several possible causes, produces confident wrong action: restarting a service that was not the problem, failing over to a secondary that shares the fault. It also destroys evidence, so the diagnosis that follows starts from a changed system.

A playbook used for a routine task wastes the automation. If a task genuinely has decision points every time, it is not routine. If it does not, writing it as branches means nobody ever collapses it into something a script can execute, and the knowledge stays with its author.

A MOP without a rollback is why a window overruns. This is the expensive one. The steps are followed, something does not come back, and the reversion is improvised at 3am by tired people in a window that is already closing. Uptime Institute's 2022 outage analysis reported that among organisations suffering a major human-error outage, 85% traced it to staff not following procedures or to the procedures themselves being flawed. A missing back-out section is the second category.

A runbook submitted as a MOP gets the change rejected. A change board is not asking how to do the work. It is asking what the impact is, who approved it, and what happens if it goes wrong. A document with no rollback and no approver answers none of those, so it bounces, and the engineer concludes the process is bureaucratic rather than that the document was the wrong kind.

A MOP skeleton

A worked shape for a real change. Nine sections; on a small change several of them are one line each, and that is fine.

MOP-2026-114   Replace core switch SW-CORE-01, Site B

1  Change summary
   Replace failed-PSU core switch with pre-staged spare.
   Two sentences. No background, no justification essay.

2  Risk and impact
   Services affected: all Site B access layer.
   Expected impact: ~6 min loss during reconvergence.
   Blast radius if it goes wrong: Site B offline until back-out.

3  Window
   Sat 10 Oct 2026, 01:00-04:00.
   Back-out decision time: 02:30.

4  Approvals
   Change owner:        [name]
   Technical approver:  [name]   approved 2026-10-06
   Business approver:   [name]   approved 2026-10-07

5  Pre-checks - do not start if any of these fail
   - Config backup of SW-CORE-01 taken, read back, diffed
   - Spare on site, correct image, licences applied
   - Out-of-band console access tested from outside the site
   - "show interface status" captured for comparison in step 7
   - No other change open against Site B

6  Steps
   6.1  ...
   6.2  ...
        Each step: the exact command, the expected output,
        and who runs it. If a step needs a judgement call,
        it is not finished being written.

7  Verification - the point of the document
   - 48 access ports up, same VLANs as the step 5 capture
   - OSPF neighbours: 4, all FULL
   - Synthetic check from Site B to two external targets: pass
   - 15 minutes of clean error counters before declaring done

8  Back-out
   Trigger:  any verification item fails, OR 02:30 arrives
             with step 6 incomplete.
   Steps:    8.1 ...  8.2 ...
   Duration: 25 min, measured in the lab, not estimated.
   Back-out is verified against the same list as step 7.

9  Post-change
   As-built and diagrams updated, monitoring re-armed,
   ticket closed with actual times rather than planned ones.

Two details do most of the work. The step 5 capture exists so that step 7 has something to compare against: "same as before" is only checkable if before was written down. And the back-out duration is measured rather than guessed, because it is subtracted from the window to produce the decision time in section 3. Guess it and the decision time is fiction.

Reconvergence time and what a single switch failure actually takes down both follow from the fabric, which is what makes section 2 answerable: inside a data center network covers how that is wired.

How detailed is too detailed

The honest test is not length. It is: can the intended reader execute this without you? Everything that serves that is in scope and everything else is padding.

Padding costs more than reading time. A document that restates the obvious teaches its readers to skim, and a skimmed document is where the one line that mattered ("take the backup before powering down") gets missed. Some working limits:

Runbook: one screen if possible. Exact commands, no explanation of what the command does. A runbook template that opens with three paragraphs of context is a training document wearing a runbook's name.
Playbook: as long as the branching needs, but every branch must end somewhere: a fix, a mitigation, or a named human.
MOP: long enough that a competent engineer who has never seen this site can follow it. MOPs are legitimately the longest of the three, because a third party may execute it and a change board must assess it.

The other end of the failure is a runbook that assumes the reader knows the hostname, the credential store, or which of two identically named devices is the live one. A document that only works for its author has not been written.

Where each one lives

The routing follows from who reads it and when.

Runbooks belong next to the system, discoverable from the alert or the service catalogue. Whoever is woken at 3am should reach it in one click from the page that woke them.
Playbooks belong with the on-call rotation, indexed by symptom rather than by system, because at the moment of the alert you know the symptom and not yet the system.
MOPs belong with the project and attached to the change record. A MOP is an artefact of one change, with a version, an approval trail, and an as-built that supersedes it.

That last one is where most teams lose them. The MOP is written in a word processor, emailed for approval, executed from a printout, and ends up in three versions across two inboxes and a share. Six months later nobody can say which one was actually run: exactly the question an audit or a post-incident review asks.

None of this requires a tool. A directory per project, a version number in the filename, and the approved copy where the ticket points gets you most of the way. The failure is rarely the software. It is that three documents with three different jobs were treated as one thing called "the doc".

Sources

Site Reliability Engineering, chapter 11: Being On-Call: Google, O'Reilly, 2016; the mean-time-to-repair claim for playbooks
Annual Outage Analysis 2022: Uptime Institute, on human error and procedure
ITIL: for the standard, normal and emergency change distinction in ITIL 4 (2019)

The categories above describe common practice rather than any single standard. ITIL 4 defines change types, not document types; runbook, playbook and MOP are industry usage, and some teams draw the lines differently. The distinction worth keeping is the last row of the table: whether the document carries a way back.