In most small businesses there’s one person who knows where the website lives, which email address the domain renews to, how the office printer got onto the network, and what to do when the online store stops taking orders. Sometimes that person is a contractor, sometimes it’s the owner’s nephew, and sometimes it’s the owner. The business runs fine until they’re on a plane, or they’ve left, or the relationship has soured, and then a routine event like a domain renewal or an expired SSL certificate turns into a week of guesswork. A runbook is the document that makes those events routine again. It isn’t complicated to write. It’s tedious, which is why it doesn’t get written.
Quick answer: A runbook lists every account the business depends on and who owns it, every renewal with its date, how to do the six or seven operational tasks that come up (deploy a change, restore a backup, renew the certificate, add a user, take a payment manually, contact the host), and who to call for each system. Credentials go in a shared password manager, never in the document. Write it by doing each task and recording the steps as you go, have someone else follow it once, and review it quarterly.
What goes wrong without one?
The domain expires because the renewal email went to a former employee’s inbox, and the website and email are down for two days while someone proves ownership to the registrar. The SSL certificate lapses and every visitor sees a security warning on the Monday of a promotion. A plugin update breaks checkout and nobody knows how to roll back, so the store stays broken until the contractor answers. A backup exists but nobody has restored one and it turns out to be of the wrong folder. The person who set up the payment gateway used their personal email, and when they leave, the gateway’s two-factor codes go with them.
None of these are technical failures. Each is a piece of information that lived in one head. We wrote about the operational side of this for software products in our post on what an app needs once it has users, and the business-wide version is the same idea with a longer list of accounts.
What should the runbook contain?
Accounts and ownership. Every service the business depends on: domain registrar, DNS provider (often different), web hosting, email provider, website platform and plugins with paid licences, payment gateway, accounting software, CRM, cloud storage, any SaaS tool that holds customer data. For each: who the account is registered to, which email address it uses, who has admin access, and where the credentials are kept. The registered email is the one that matters most, because it’s where password resets and renewal notices go, and it should be a role address like admin@yourbusiness that more than one person can read.
Renewals and expiries. Domain, SSL certificate if it isn’t automatic, hosting plan, software licences, and any contract with a notice period. Dates, costs, and the payment method on file, because a card that expires is a renewal that fails.
Procedures. The tasks that happen a few times a year and that nobody remembers between times. How to put the website into maintenance mode. How to roll back a change. How to restore a backup, tested. How to renew the certificate. How to add or remove a staff member from every system (the leaver checklist is the one that protects you). How to process an order or take a payment if the website is down. How to reach the host, the developer, and the payment provider, with account numbers.
Contacts. The developer or agency, the host’s support line, the accountant, the registrar, with the account references each will ask for.
What normal looks like. A short note on what the business expects from each system: the website should load in under three seconds, orders should reach the warehouse within five minutes, the backup should run nightly and email a confirmation. Without this, a person following the runbook can’t tell whether the thing they did worked.
How do you write it without it taking a month?
Do each task and write the steps while doing it. Don’t try to write from memory; the steps you forget from memory are the ones that break the process for someone else. Start with the three procedures that would hurt most if they were needed tomorrow, usually restore a backup, roll back the website, and the leaver checklist, and let the rest accumulate over a quarter.
Keep it in one place, in a format anyone can open: a shared document, a wiki page, a folder in the company’s cloud storage. Link to it from wherever people already look. A runbook that lives on one person’s laptop has the same problem it was meant to solve.
Credentials never go in the document. Use a password manager with shared vaults, put the runbook’s steps in the document, and put “the login is in the Ops vault” where a password would be. The runbook can be shared widely then, and access to the vault can be managed separately.
Then test it. Have someone who didn’t write it follow the backup restore procedure on a staging copy. Where they get stuck is where the document is wrong. This is the step almost everyone skips and it’s the one that makes the document worth having.
Who should maintain it?
Whoever owns operations, with a quarterly review on the calendar: are the accounts still right, have any renewals moved, did any procedure change with a software update. If the business has a maintenance arrangement with a developer or agency, keeping the runbook current for the systems they touch is a reasonable thing to include in it, and a provider who won’t do that is telling you something. The same applies if you’re thinking about whether you’ve outgrown your current web developer; one of the fair questions to ask is whether they could hand the site over cleanly tomorrow, and the runbook is what makes the answer yes.
The runbook is also what makes it possible to bring in a fractional team or a new contractor without a month of archaeology. We produce one as the first deliverable of most digital transformation engagements, because until it exists nobody, including us, can safely change anything.
Frequently asked questions
Isn’t this what an IT provider is for?
A managed IT provider will know the systems they manage, and usually not the website, the payment gateway, or the SaaS tools the marketing team signed up for. The runbook is the business’s own record, and it’s also what lets you change providers.
How long does it take to write?
The account inventory takes an afternoon. Each procedure takes as long as the task plus a little, if you write while doing it. Expect a usable runbook in a couple of weeks of small sessions, and a good one after the first quarterly review.
What format should it be in?
Whatever people will open. A shared document with headings and a table of contents is fine. Avoid formats that need special software or a licence. The test is whether a new hire can find and read it on their first day.
Where do the passwords go?
In a password manager with shared vaults and per-person access, never in the runbook. The runbook refers to the vault by name. When someone leaves, you remove their vault access and rotate what they had, using the leaver checklist in the runbook.
What if the person who knows won’t cooperate?
Start with what you can access. The registrar, the host, and the payment gateway will all confirm which email an account is registered to if you can prove the business owns it, and recovering those three gives you leverage over the rest. Do it before the relationship gets worse, not after.
How often should we test the backup restore?
Twice a year at least, and after any change to hosting or backup tooling. A restore that has never been tested is a hope, and the runbook should record when the last test happened and what it found.