Server runbook template
Everything someone needs to keep a server running when the person who built it isn't there: access, dependencies, routine jobs, backups, and fixes for the usual problems. Free, in Word or Markdown.
- Contacts
- Who to call, and when
- Access
- Where the keys are kept, never the keys
- Routine work
- Deploys, restarts, patching, renewals
- Backups
- What, where, and the last restore test
- Fixes
- Symptom, cause, check, fix
Why write one
Most small server estates live in one person's head. That works until they're on holiday, ill, or gone, and then a routine restart becomes a morning of guesswork.
A runbook moves that knowledge onto paper. It is also what customers' security questionnaires and ISO 27001 auditors mean when they ask for "documented operating procedures".
The eleven sections
| Section | What goes in it |
|---|---|
| 1. What this service is | What it does, who uses it, what an outage costs, and its recovery targets. |
| 2. Contacts and escalation | Who responds first, who to escalate to, and the provider and developer contacts. |
| 3. Servers and architecture | Each server's role, provider, region, OS version and size, and how a request flows. |
| 4. Access | How to log in, where credentials are kept, break-glass access, and leaver steps. |
| 5. Dependencies | DNS, email, payments, storage, certificates and the domain, with what breaks if each fails. |
| 6. Monitoring and alerts | What is watched, where alerts go, and what each one means. |
| 7. Routine operations | Deploys and rollbacks, restarts, logs, scheduled jobs, patching and renewals. |
| 8. Backups and restore | What is backed up, where, how often, and the restore steps, with the last test date. |
| 9. Common problems | Symptom, likely cause, how to check, and the fix. |
| 10. Security incidents | The signs to act on, the first steps, and the 72-hour rule for personal data breaches. |
| 11. Change log | What changed in the runbook, when, and who changed it. |
Making it useful
Write for a stranger. Assume the reader is competent but has never seen this system. Exact commands beat descriptions.
Keep it off the server. A runbook stored only on the machine it describes is lost in the outage it was written for.
Test it. Have someone else follow it, ideally for a real restore. Every place they get stuck is a gap.
Date the restore test. "Last test restore" is the most important line in the document. If it's blank, that's the first job.
Questions
What is a server runbook?
A written guide to running one service or server: how to get in, what it depends on, how to deploy, restart and patch it, where the backups are and how to restore them, and how to fix the problems that come up. It is written so that someone who has never touched the system can keep it going.
What is the difference between a runbook and a playbook?
The words are often used for the same thing. Where they differ, a runbook covers the routine running of one system, step by step, and a playbook covers a type of situation, such as a security incident, across many systems. This template is a runbook, with a short section on security incidents.
How is a runbook different from a disaster recovery plan?
A runbook is the detail for one system. A disaster recovery plan sits above it: who decides, what comes back first, and how people are told. The plan points to the runbooks for the actual steps. There is a free disaster recovery plan template to go with this one.
Should passwords go in the runbook?
No. Say where credentials are kept, usually a password manager, and who can get them. A runbook gets copied, shared and printed; secrets in it end up everywhere.
Where should a runbook be kept?
Somewhere everyone who might need it can reach during an outage, which means not only on the server it describes. A shared wiki or repository is common, with an exported copy somewhere separate.
How often should a runbook be updated?
After every change it describes, and reviewed on a schedule, such as every six months. The best test is to have someone who didn't write it follow it, and fix whatever they get stuck on.
Rather not write it from memory?
The £250 GUARD review finds out how your servers really run: access, updates, backups and alerts, with the fixes in order. It's most of a runbook. Book a call to start.