Website Reliability Planning: Writing a Recovery Runbook Before the Next Outage
Most small businesses discover their website's weak points at the worst possible moment: when the homepage stops loading and nobody is quite sure who can fix it, where the login is stored, or what order things should be checked in. A recovery runbook is a plain written document that answers those questions ahead of time. It does not require specialized software or a large team. It requires a few hours of honest thinking and a willingness to write down what you currently assume. This article walks through how to build one, what belongs in it, and which questions will expose the gaps most likely to slow you down.
What a Runbook Is and Why It Beats Memory
A runbook is a step-by-step written guide for handling a specific situation. For a website, the situation is usually some form of unavailability: the site is down, pages load slowly, forms stop submitting, or email tied to the domain behaves strangely. The purpose of the document is to replace improvisation with a sequence that someone other than the original builder can follow under stress.
Small businesses often rely on memory. The person who set up the site knows where the hosting account lives, which email address receives renewal notices, and why a certain setting was changed last spring. When that person is unavailable, the knowledge is unavailable too. A runbook moves that knowledge out of one head and onto paper where it can be reviewed, updated, and shared.
The document should be short enough to read during an emergency. Aim for a few pages with clear headings rather than a binder nobody opens.
Inventory the Pieces Before Writing Steps
Before writing any procedure, list every component your web presence depends on. This is the dependency inventory, and it usually turns up more items than expected. Typical entries include the domain registrar, the DNS provider, the hosting account, the content management login, the email service that shares the domain, any payment or booking tool embedded in the site, analytics accounts, and the email address that receives account notices.
For each item, record the account holder's name, the login location in a secure place, the contact route for that provider, and the date the account renews. Renewal dates deserve special attention because lapsed domains and expired certificates cause outages that look mysterious until someone checks the calendar.
Write down who has administrative access to each item. If the answer is a single person or a single personal email address, flag that as a risk. The goal is not to assign blame but to notice concentration.
Questions to Settle Before an Outage Occurs
A useful runbook begins with decisions rather than commands. Several questions should be answered in writing before anything breaks. Who is the first person to be contacted when the site goes dark, and what is their backup? What counts as an outage worth acting on, versus a brief blip? Who is authorized to contact the hosting provider or change DNS records? Where do you go to confirm that the problem is the website and not a local network issue or a browser cache?
Consider also what the business will tell customers and through which channel. A temporary notice on social media or a phone greeting can reduce confusion, but only if someone has agreed on the wording and the person who posts it.
Finally, ask what the acceptable recovery window is. Some businesses can tolerate a few hours without a site; others lose bookings within minutes. Writing a rough target, even an uncertain one, gives everyone a shared sense of urgency and helps decide when to escalate.
Writing the Steps and Testing Them
Once the questions are answered, draft the steps in the order a responder would naturally check them. A common sequence starts with confirming the problem from more than one device and network, checking the status pages of the hosting and DNS providers, verifying the domain's registration status and renewal date, reviewing recent changes made to the site or its records, and then contacting the appropriate provider with account details ready.
Each step should name the person responsible and describe what a successful check looks like. Avoid vague instructions such as 'check the server.' Instead write 'load the homepage in a private browser window from a phone on cellular data and note whether it returns an error page.'
A runbook that has never been tested is a guess. Walk through the document once with a colleague or during a quiet afternoon. Look for steps that require credentials nobody can locate, contacts with outdated phone numbers, and assumptions that only the original builder would understand. Revise until a fresh reader can follow it without asking questions.
A Brief Checklist for Your First Draft
The following items make a practical starting point. Keep them in plain form in your working document and check them off as you confirm each one.
Confirm the domain registrar, the expiration date, and who receives renewal notices. Confirm the DNS provider and where records are edited. Confirm the hosting provider, the account owner, and the support contact route. List every login the site needs, where each is stored, and who can access it. Name a primary responder and a backup responder with phone numbers. Write the order of troubleshooting checks. Record the business's rough tolerance for downtime. Draft the wording for a customer-facing notice. Schedule a review date, perhaps every three months, to update contacts, renewals, and access lists.
Compare two approaches to keeping this document current. One is a shared folder that everyone can edit, which is easy to update but can drift if nobody owns it. The other is a single owner who reviews it on a schedule, which is more disciplined but depends on that person staying in the role. Many small businesses benefit from combining both: a shared location for access and a named owner who checks it on a fixed date.