What makes a good operational runbook?

A good runbook lets a tired on-call engineer execute a procedure correctly at 3am without prior knowledge. It is specific, numbered, includes verification after each major step, and always states how to roll back if something goes wrong.

Why include verification and rollback steps?

Verification tells the operator the change actually worked rather than assuming it did. Rollback steps mean a partial failure does not turn into an outage because nobody knew how to undo the change. Both are mandatory in production runbooks.

Should every runbook list escalation contacts?

Yes. The operator running a procedure may not own the system. Listing who to page and when prevents a stuck on-call engineer from sitting on a problem because they did not know who could help.

How is a runbook different from a disaster recovery plan?

A runbook covers one routine or incident procedure, such as rotating a credential or clearing a queue. A DR plan covers restoring whole systems after a major failure and includes RTO and RPO targets. Use the DR plan builder for the latter.

Is anything I type stored or uploaded?

No. The builder runs entirely in your browser. Your runbook content is never sent to a server, so it is safe for internal procedures and sensitive operations.

Operational Runbook Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Turn tribal knowledge into a repeatable procedure

The most dangerous operational knowledge is the kind that lives in one engineer’s head. A runbook captures a procedure so anyone on call can execute it safely and consistently. This builder produces a structured Markdown runbook with every section a good procedure needs: overview, prerequisites, numbered steps, verification, rollback, and escalation.

How it works

The builder assembles a standard runbook layout from your inputs. The Overview states what the procedure does and when to use it. Prerequisites lists the access, tools, and conditions required before starting. The Procedure is your raw steps rendered as a numbered list so they are executed in order. Verification describes how to confirm success. Rollback explains how to safely undo the change. Escalation records who to page if the procedure fails.

Each step you type on its own line becomes a numbered item, and list fields like prerequisites and escalation render as bullets. The output is plain Markdown that pastes cleanly into Confluence, Notion, or a Git wiki.

Tips and example

Write each procedure step as a single concrete action: “Run kubectl rollout restart deployment/api”, not “restart the service”.
Add a verification step after any irreversible action so the operator knows immediately whether to continue or roll back.
Keep prerequisites honest — list every credential, VPN, and permission needed, because a missing one stalls the whole procedure.
Include the escalation path even for routine runbooks. The person executing at 3am may not be the system owner.