Explainer
What a tech runbook is, and why every business needs one
A runbook documents what your systems are and how to operate them. Here is what goes in one, why vendors avoid writing them, and how to demand one.
Kaci Cox
This is a published outline, not a finished post. The argument and structure are here so you can see what is coming. It will be written properly rather than padded out to hit a word count.
What this post will cover
The single cheapest protection against vendor lock-in, and why almost nobody has one.
Outline
What a runbook is
- A written record of what each system is, what it connects to, who can access it, and what to do when it breaks.
- Not architecture documentation. Operational instructions a non-expert can follow.
The test
- If your web person stopped answering tomorrow, could someone else take over in a day?
- Most owners discover the answer during the emergency.
What belongs in one
- Every account, where it lives, who owns it.
- Domain and DNS: registrar, renewal date, who has access.
- Hosting and deployment: how a change goes live.
- Integrations and what breaks if each one stops.
- Backups: where they are, and when one was last restored rather than merely taken.
- Escalation: who to call, in what order.
Why vendors do not write them
- Documentation and handover. Say this plainly.
- Distinguish deliberate lock-in from ordinary disorganisation.
How to get one
- Ask for it in the contract as a deliverable with a date.
- What to do if a current vendor refuses.
Link to the public sample runbook.
Notes before writing
- This post is a trust argument as much as an explainer. Keep it concrete.