Website Reliability Planning: Writing Down Your Assumptions Before Trouble
Most small business websites run on a set of assumptions that nobody wrote down. Someone assumes the domain renews automatically. Someone assumes the hosting account is in the company name. Someone assumes the person who built the contact form still answers email. These assumptions hold quietly for months, then fail together on the day the site goes down and everyone needs an answer at once. Writing them down ahead of time is one of the cheapest reliability habits available. It costs an afternoon, requires no special tools, and turns vague confidence into a list you can check. This article walks through how to build that list, what questions belong on it, and how to use it when you talk to any outside helper, whether that is a remote support provider, a local technician, or your own staff.
Why unwritten assumptions cause outages
A website is rarely a single thing. It is a domain name, a DNS configuration that points that name somewhere, a hosting environment, a content management system or site builder, a set of plugins or integrations, an email setup that often shares the domain, and a human or group of humans who hold the logins and billing relationships. Each piece has an owner, and each owner made decisions at some point that the rest of the business may not know about.
The usual failure pattern is not a dramatic attack or a hardware fire. It is a renewal notice sent to an old email address, a payment method that expired, a certificate that was never set to renew, or a plugin update that broke a page nobody checks. These problems are predictable, and most of them were predictable at the time the setup was created. The reason they surprise people is that the assumptions behind them lived only in someone's head, and that someone may have moved on.
Building an assumptions inventory
Start with a blank page and list every component the website depends on. Be concrete: the registrar where the domain is held, the account that pays for hosting, the email platform that receives messages sent to the domain, the form tool, the analytics account, and any third-party widget that loads on the homepage. For each item, write down who created it, who currently controls it, and what email address or phone number receives its notices.
Next, for each item, write one sentence that begins with the word 'assumes.' For example: 'Assumes the registrar sends renewal notices to the office manager's inbox, which she still checks weekly.' Or: 'Assumes the hosting plan renews on a credit card that is current.' These sentences are the useful part. Once they are written, they are easy to test. A question such as 'Does the office manager still work here?' or 'When was that card last confirmed?' becomes a concrete action rather than a vague worry.
Questions to ask before you need help
A written inventory also gives you the answers an outside helper will ask first. Before you contact any support provider about a website problem, you should be able to answer several questions: Where is the domain registered, and under which account? Who can approve changes to DNS records? Where is the website hosted, and is the account under your business name? Which email address receives account notices for each service? Is there a documented way to reset access if the person who held it leaves?
You should also ask yourself what you would need to know if the site went down right now. Is there a recent backup, and where is it stored? Do you know how the site was built, and is there a copy of the source files or content outside the hosting environment? Who has permission to make emergency changes, and how would you reach them after business hours? If these questions produce uncertain answers, that uncertainty is the work to do next, not a sign that something has already failed.
A practical reliability checklist
Use the following checklist once a quarter, and whenever a staff member with account access leaves the business. First, confirm that the domain registration shows the correct owner organization and a current contact email that someone monitors. Second, confirm the expiration date and check that automatic renewal is enabled with a valid payment method, while also verifying the renewal notices reach a person who will act on them. Third, confirm that the hosting account is in the business's name and that at least two people have administrative access.
Fourth, verify where the most recent copy of the website content lives, outside the hosting account itself, and when it was last checked. Fifth, list the third-party services embedded in the site and note what happens if each one stops working. Sixth, write down the name and contact method of the person to call first, the person to call second, and the outside helper you would use if neither is available. Seventh, record the date of your last test of any restore or recovery step, even if the answer is 'never.' That last item often reveals the biggest gap.
When you finish, keep the document somewhere accessible to more than one person. A reliability plan that only one employee can find is another single point of failure. Revisit it when you change hosts, add a new integration, or hire. The goal is not a perfect system. It is a current, shared picture of your assumptions so that when something breaks, the first hour goes to fixing the problem rather than hunting for the account login.