It is 2 a.m., something has broken, and the one person who knows the fix is on a plane. Whether the problem is a failed payment run, a dead server or a stuck order queue, the next hour depends on one thing: is the knowledge written down, or is it only in someone’s head? A runbook is how you write it down. This guide covers what a runbook is, how it differs from an SOP, and how to write one that people actually open when they are under pressure.
What is a runbook?
A runbook is a short, practical guide for handling a specific situation: a recurring task, a known failure or an incident. It tells the person on duty what triggered the situation, who owns it, exactly what to do, how to undo it if things get worse and who to call. The test of a good runbook is simple: could a competent colleague who has never done this task follow it alone, at night, without calling you?
Runbook vs SOP: what is the difference?
The two overlap, and many teams use the words interchangeably. A useful distinction:
- An SOP (standard operating procedure) describes how routine work should always be done, such as onboarding a supplier or closing the month. It is about consistency and compliance, and it is usually read in advance.
- A runbook describes how to respond to a particular event or perform a specific operational task, often under time pressure. It is about speed and safety, and it is read in the moment.
An SOP can be thorough and a little formal. A runbook should be blunt: short sentences, exact commands, no background essays. Link from the runbook to the SOP when someone needs the “why”.
When should you write a runbook?
You cannot document everything, so start where the pain is. Write a runbook when:
- A task is repeated and costly to get wrong, such as monthly payroll exports or a release.
- An incident has happened twice. The second time is the signal.
- Only one person knows how to do something. That is a risk, not an asset.
- A task is rare but critical, like restoring from backup. Nobody remembers rare procedures.
- New starters keep asking the same questions.
What should a runbook contain?
Keep the same five parts in every runbook, so people always know where to look.
- Trigger. When to use this runbook: the alert, symptom or calendar date. “Checkout error rate above 5% for ten minutes” is a trigger. “When things look bad” is not.
- Owner. One named person or role responsible for keeping it accurate, plus a date of the last review.
- Steps. A numbered list, one action per step, in the order they should happen, each with the expected result so the reader knows it worked.
- Rollback. How to return to the previous state if a step fails or makes things worse. Write this before you need it.
- Escalation. Who to contact if the steps do not solve it, in what order, how, and after how many minutes of trying.
How do you write steps people will follow?
One action per step
“Restart the service and check the logs” is two steps. Split them, so a person under stress cannot skip half.
Be exact
Give the real command, the exact menu path or the actual link. “Open the admin panel” forces the reader to guess. Copy-paste beats interpretation at 2 a.m.
State what success looks like
After each key step, write what the reader should see: “The status page shows Running.” If it does not, they know to stop and escalate rather than continue blindly.
A short example
Here is the outline of a runbook for a stuck order queue:
- Trigger: more than 50 orders waiting for over 15 minutes.
- Owner: operations lead; last reviewed in September.
- Steps: check the processor status page; restart the queue worker; confirm that the waiting count is falling within five minutes.
- Rollback: if the restart creates duplicate orders, pause the worker and follow the duplicate-order cleanup guide.
- Escalation: if the queue is not moving after 20 minutes, call the engineer on call, then the operations director.
How do you test a runbook?
An untested runbook is a guess. Give it to someone who did not write it and have them follow it, ideally in a safe environment or a drill, while you watch silently. Every place they hesitate, ask a question or improvise is a gap to fix. Run these drills once or twice a year for critical runbooks. After every real incident, ask one more question in the review: did the runbook help, and what would have made it better?
How do you keep a runbook current?
- Give every runbook an owner and a review date. Quarterly for critical ones, twice a year for the rest.
- Update after every use. The person who just followed it knows best what was wrong or missing, so make fixing it part of closing the incident.
- Tie it to change. When a system, tool or supplier changes, updating the related runbooks belongs on the same checklist.
- Keep it findable. A perfect runbook in a forgotten folder is useless. Store them in one place, with clear names, linked from the alert itself where possible.
Where to keep your runbooks
A shared document or wiki is enough to start. What matters more than the tool is that runbooks sit close to the work. If you already track operations, tasks and KPIs in FulcrumGrid Command Center, you can link each runbook to the project or metric it protects, and assign review dates to owners like any other task, so they do not quietly expire. But start with whatever your team will really open.
Pick the one incident that hurt most last quarter, write its runbook this week, and test it with someone new. A single good runbook will do more for your team than a binder full of untested ones.
Frequently asked questions
Is a runbook the same as a playbook?
The words overlap. Many teams use a runbook for exact, step-by-step technical or operational actions, and a playbook for broader strategy, such as how to run a major incident or a customer escalation, which may point to several runbooks.
How long should a runbook be?
As short as possible, ideally one or two pages. If it needs more, split it into smaller runbooks or link to background material instead of burying the steps.
Who should write the runbook?
The person who does the task today should draft it, because they know the details. Then someone who has never done it should test and edit it, because they spot the missing assumptions.
How often should runbooks be reviewed?
Review critical runbooks every quarter and the rest twice a year. Update any runbook straight after it is used in a real incident or when the system it covers changes.
FulcrumGrid Command Center
Keep your runbooks tied to the work
FulcrumGrid Command Center helps you track tasks, owners and KPIs in one place, so runbook reviews are assigned and nothing quietly goes stale.