Website Reliability Planning: Writing Your Recovery Runbook in Plain Language
Most small businesses discover their website's weak points during an outage, when the person who set up the domain is unreachable, the hosting login has been forgotten, and nobody is sure whether the problem is the site, the DNS, or the email. A recovery runbook is a short written document that answers these questions ahead of time. It does not need to be long or technical. It needs to be specific enough that someone who did not build the site can follow it on a bad day. This article walks through how to write one, what to include, and which questions to answer first.
Start With the Outage You Are Actually Planning For
A runbook is easier to write when you pick a concrete scenario. Instead of trying to plan for every possible failure, describe one realistic event: the public site returns an error page, or the contact form stops delivering messages, or the site loads slowly for customers. Each scenario needs a different first step. A site that shows an error may point to hosting or a recent change, while a site that loads but has no working email may point to DNS records or the mail configuration.
Write one short runbook per scenario, starting with the two or three you consider most likely to affect revenue or customer trust. Keep each one to a single page. If a scenario takes longer to describe than that, it is usually two scenarios bundled together, and splitting them will make both easier to follow under pressure.
Inventory the Pieces That Can Fail Independently
A business website is rarely one thing. It is usually a domain registration, a DNS zone that points names to services, a hosting account or platform, a content management system or site builder, a mail service, a form or booking tool, and sometimes a payment or analytics integration. Each of these can fail independently, and each may be managed by a different login, a different company, or a different person.
List every piece in a simple table or bulleted list. For each one, record where it is managed, who holds the login, what the renewal or expiration date is, and what breaks if it stops working. This inventory is the foundation of the runbook, because it tells you which steps depend on which accounts. Many small teams find that one renewal date or one forgotten payment method is the entire cause of their worst outage.
Answer the Questions Before You Need the Answers
A runbook is mostly a set of answers written down in advance. The questions below are the ones most often missing when a small business is stuck during an outage. Write the answer next to each one, even if the answer is "not sure yet," because that gap is itself useful information.
Who can log in to the domain registrar, and is that login tied to a personal or company email address? Who can change DNS records, and can they be reached on a weekend? Where is the hosting account, and what is the name of the company or platform? Who receives renewal notices, and does that inbox still get checked? What is the expected response from the hosting provider during business hours versus outside them? Is there a second person who has been shown how to access each system? Which changes were made in the last thirty days, and who made them? If the site is down, what is the first public message you would post, and where?
These answers usually expose at least one single point of failure. If one person is the only one who can reach the registrar, that is a risk to write down and address, not something to fix in the middle of an incident.
Write Steps Someone Else Can Follow
Each runbook step should name an action, a location, and an expected result. Instead of "check DNS," write "sign in to the registrar, open the DNS record list for the primary domain, and confirm the A or CNAME record for the main site points to the address listed in the hosting inventory." Instead of "contact support," write "open a ticket with the hosting provider using the account name in the inventory, and include the time the problem started and the exact error text."
Order the steps from least to most disruptive. Checking status pages, reviewing recent changes, and confirming renewal dates come before restarting services or changing records. Include a line that says what not to do, such as avoiding edits to DNS during a live incident unless someone with authority has approved it. This prevents well-meaning fixes from creating a second problem.
A Short Checklist for Reviewing Your Runbook
Once the draft is written, review it with someone who did not write it. Ask that person to read one scenario and explain the first three steps back to you. If they hesitate, the wording needs work. Confirm that every login has a named holder and that the holder knows where the credentials are stored. Check that every renewal date is on a calendar that more than one person can see.
Finally, store the runbook somewhere accessible when the main website and the main email are both unavailable. A printed copy in the office or a document kept in a separate account is often more useful than a file stored only on the system that just failed. Review the runbook at least once a year and after any major change to the site, the hosting, or the people who manage them. A runbook that matches your current setup is worth far more than a detailed one that describes a site you no longer run.