Runbook
A runbook is a documented set of operational procedures that IT and DevOps teams use to carry out a specific routine task or respond to a particular incident consistently. It captures the exact steps, commands, and checks needed to perform or recover an operation reliably.
What is a runbook?
A runbook is an SOP for operations work. It documents how to perform a specific technical procedure — restarting a service, rotating a certificate, restoring from backup, responding to a particular alert — so that whoever is on call can execute it reliably, even at 3 a.m. under pressure. The name comes from the operator's manual once kept beside the machines; the idea is unchanged, just applied to modern IT systems.
Runbooks come in two broad flavors. A routine (or standard) runbook covers scheduled, predictable work — deployments, maintenance, backups. An incident (or emergency) runbook covers responding to something going wrong — a specific outage, a failing health check, a security event — with the diagnostic steps and remediation actions to bring the system back. Both exist to remove guesswork from operations that are too important to improvise.
A good runbook is precise and executable. It names the exact commands to run, the expected output, the checks to confirm each step worked, escalation paths if it doesn't, and links to dashboards or logs. The aim is that someone who didn't build the system can still operate it correctly by following the runbook — turning tribal ops knowledge into a repeatable procedure the whole on-call rotation can rely on.
Key characteristics
Operational and executable
A runbook is written to be acted on, often during an incident. It lists exact commands, expected outputs, and verification checks — not general guidance.
Scoped to one procedure
Each runbook covers a single routine or incident — one deployment, one type of outage. Broad "how we run everything" documents belong elsewhere.
Built for on-call reliability
The audience is whoever is on call, possibly unfamiliar with this system and under time pressure. Clarity and unambiguous steps matter more than elegance.
Includes verification and escalation
Good runbooks say how to confirm each step worked and what to do — who to page, what to roll back — when it doesn't.
Kept current or it's dangerous
A stale runbook is worse than none, because people trust it under pressure. The best ones name an owner and get verified as systems change.
Runbook vs playbook
The terms overlap and teams use them loosely, but there's a useful distinction: a runbook is procedural and specific, a playbook is strategic and broader.
| Runbook | Playbook | |
|---|---|---|
| Scope | One specific procedure or incident, step by step | A broader strategy or class of situations |
| Detail | Exact commands, checks, and expected outputs | Roles, decisions, and coordination across a response |
| Answers | Exactly how to execute this operation | How to approach and coordinate a whole scenario |
| Typical use | Restart a service, restore a backup, respond to a specific alert | Major incident response, security breach coordination, launch strategy |
| Relationship | A playbook may invoke several runbooks | Orchestrates runbooks and human decisions together |
What to include in an IT runbook
- 1A clear title naming the specific task or incident the runbook covers.
- 2When to use it — the trigger, alert, or schedule that calls for this procedure.
- 3Prerequisites: required access, credentials, tools, and safe preconditions.
- 4Numbered steps with the exact commands to run and their expected output.
- 5Verification checks that confirm the system is in the right state after each step.
- 6Rollback and escalation paths for when a step fails or the fix doesn't hold.
- 7Links to relevant dashboards, logs, and the runbook's owner and last-reviewed date.
How Glyde fits
Much of the operational knowledge a runbook should capture lives in the browser — the admin consoles, cloud dashboards, and internal tools where operators actually click through a procedure. Glyde captures those workflows the same way it captures any process: you perform the routine once while recording, and it produces numbered, annotated steps with screenshots of the real screens involved, so the browser-based parts of a runbook get documented as you do them rather than written from memory afterward.
Glyde isn't a command-line automation tool, so it won't replace the executable scripts at the core of infrastructure runbooks. Where it earns its place is the human-operated, UI-driven side — and because consoles and dashboards routinely expose tokens, account IDs, and customer data, SmartBlur redacts that PII on-device before the screenshots leave your machine. For the many operational procedures that are really "click through this tool correctly," that turns undocumented tribal knowledge into a step-by-step guide the on-call rotation can follow.
Runbook, answered
What is a runbook in simple terms?
What's the difference between a runbook and a playbook?
What should an IT runbook template include?
What's the difference between a runbook and an SOP?
Related terms
Standard Operating Procedure (SOP)
A documented, repeatable set of steps for doing a task the same way every time — what goes in one, formats, and how to build them.
Process Documentation
Recording how a process is performed so it can be followed, improved, and scaled — what it includes and the fastest way to do it.
Screen Recording
Capturing what's on your display as video or steps — how it works, common uses, and how a recording becomes an SOP.
Turn your next recording into a real SOP
Record once, get documentation your team can follow on day one. Free plan, no credit card required.
Try Glyde Free