Website Reliability Planning: Writing Down Your Recovery Assumptions
Most small businesses discover their website recovery assumptions the hard way. The site goes down, someone asks where the login is kept, and the answer turns out to be a personal inbox nobody checked in months. Recovery planning is less about buying tools and more about writing down what you currently assume is true, then checking whether those assumptions hold. This article walks through a method for doing that without requiring a technical background, and it focuses on the questions worth asking your own team and any outside provider you work with.
Why assumptions are the real risk
Every website depends on a set of unstated beliefs. You may assume the domain renews automatically, that the person who built the site can still be reached, that a backup exists somewhere, or that the hosting account is in the company name rather than an employee's. Each belief is reasonable on its own. The risk comes from stacking several of them, since a single broken assumption can turn a small problem into an extended outage.
Writing these beliefs down changes the conversation. A written list is easy to review, easy to hand to a new team member, and easy to compare against reality. Without one, recovery planning happens only during an emergency, when people are guessing under pressure. A short document created on a calm afternoon is far more useful than a detailed plan created during a crisis.
Building the assumptions inventory
Start with a plain list of everything the website touches. Include the domain registrar, the DNS provider, the web host, any content management login, the email systems tied to the domain, forms or payment tools embedded on the site, and any third-party scripts. For each item, record who owns the account, which email address is attached to it, where the login credentials are stored, and when the next renewal or billing date falls.
Then add a column for the assumption behind each entry. For example, 'the registrar account is under the owner's name and billing is on a company card' or 'the host sends renewal notices to the operations inbox.' Writing the assumption forces you to say out loud what you have been taking for granted. Many teams find that at least one entry on their list rests on a belief no one has verified in years.
Testing what you wrote down
An inventory is only a hypothesis until you check it. Pick three or four assumptions and verify each one directly. Log into the registrar and confirm the account email. Check whether the renewal notice address is one that someone currently reads. Ask whether the person listed as the site contact still works at the company. Confirm that the credentials stored in your password manager actually open the accounts they describe.
Record the result of each check, including the date and who performed it. If a check fails, treat that as a finding rather than an embarrassment. Fixing a stale email address on a registrar account takes minutes; discovering the problem after a lapsed domain takes days and can cost you customers who cannot reach the site.
Questions to ask your team and your providers
Certain questions reveal gaps faster than any checklist. Ask who can approve a change to the site and who can make that approval while traveling. Ask what happens if the primary contact leaves the company, and whether anyone else holds administrative access. Ask how the team would learn that the site was down, whether from a customer, a monitoring message, or a phone call from a friend.
When you talk with an outside technology provider, ask specific, factual questions. Which accounts will they need access to, and who on your side authorizes that access? What information do they need from you to understand your site's setup? Where should they send their questions, and what hours can your team reasonably expect a response? Pay attention to answers that stay vague. A provider who can clearly explain how they document access and handoffs is usually easier to work with than one who relies on memory.
A practical checklist to keep
Keep a single page with these items: the list of accounts and their owners, the email address attached to each, the location of stored credentials, the renewal dates, the names of two people who can act in an emergency, and the date of your last verification. Review the page every quarter, and update it whenever someone joins or leaves the team, changes a vendor, or moves a service to a new account.
Store the page where the people who need it can reach it during an outage, which may mean a copy outside the systems that might be down. Remember that the document itself is an assumption too: it is only useful if someone checks it. Set a recurring reminder, assign the review to a named person, and treat a missed review as a small warning sign rather than a formality. Reliability planning is mostly the habit of writing things down and then confirming they remain true.