Website Uptime Assumptions: Writing Down What You Think Will Happen
Most small business websites run on a set of assumptions nobody has written down. Someone assumes the hosting renews automatically, that a particular person receives the alert emails, that the backup exists, or that the contact form still delivers messages. These beliefs feel like facts until the day they are wrong. An assumption log is a plain document that lists what you believe about your website, why you believe it, and how you would find out if you were mistaken. It costs an afternoon to create and it turns a vague worry into a sequence of questions you can answer. This article explains how to build one, what to include, and how to review it without pretending to know more than you do.
Why Unwritten Assumptions Cause Real Outages
A website is rarely one thing. It is a domain name registered with one company, a DNS configuration that may live somewhere else, a hosting account, a content management login, a form tool, an email address for customer messages, and sometimes a third-party script that loads on every page. Each piece has its own renewal date, its own login, and its own contact. When a business owner says the site is fine, they usually mean the public page loads on their own device. That is a narrow test.
The gap between what owners believe and what is actually true tends to show up at the worst time. A domain expires because the renewal notice went to an inbox nobody checks anymore. A form stops sending because a plugin update changed a setting. A staff member who once handled everything leaves, and their password manager entry is the only record of the hosting login. None of these failures are exotic. They happen because the assumptions behind the site were never examined.
The first step is therefore humility about your own knowledge. Treat every statement about your website as a claim that needs a source. If you cannot name where the information came from, mark it as unverified.
Building the Assumption Log
Create a simple table or spreadsheet with four columns: the assumption, the person or record that supports it, the date you last confirmed it, and the test that would prove it wrong. Keep the language concrete. Instead of writing that the website is backed up, write that a copy of the site files and the database exists, that it was created in a named location, and that someone has opened it recently.
Cover the main categories. Start with ownership and access: who holds the domain registrar login, the hosting login, the email account tied to the domain, and the content editor credentials. Then cover renewals: which services bill automatically, which require manual action, and where renewal notices are sent. Add contact and alerting: who receives downtime notices, form submissions, and security messages, and whether those addresses still reach a working mailbox. Include change history: whether anyone records what was changed, when, and by whom.
For each row, write the test in plain terms. A test might be to submit the contact form from a personal phone and confirm the message arrives. It might be to log into the registrar with the credentials stored in your password manager and read the expiration date. It might be to ask the person named in the alerts field to forward a test message and report whether it arrived. Tests that require no special skill are the most valuable because you can repeat them quarterly.
Questions That Expose the Weak Spots
Certain questions surface assumptions faster than a list of components. Ask who could restore the site today if the primary administrator were unavailable for a week. Ask what happens to the business if the domain stopped resolving tomorrow, and how long the owner would take to notice. Ask whether any account depends on a personal email address belonging to someone who may leave. Ask what would be lost if the form provider changed its terms or shut down a feature.
Ask about the recovery path, not only the prevention path. Owners often describe protections without describing what they would do after a failure. Write down the steps you would take, the person you would call, and the information you would need on hand. If the answer is that you would search for the login later, you have found a gap worth closing now.
Be cautious about answers that depend on a provider's promises you have not read. If you cannot find documentation describing what a service does during an outage or how data is retained, record that as an open question rather than an assumption of safety. Asking a vendor directly for their written policy is a reasonable step.
A Short Checklist for Your First Review
Work through these items in order and note the date you finish each one. First, list every account tied to the website, including the registrar, DNS host, hosting provider, email service, content tools, and any form or script vendors. Second, record the owner and backup contact for each account, and confirm that the owner's email is one that the business controls. Third, locate the renewal or expiration date for each paid service and set a reminder that goes to at least two people. Fourth, perform one test of each alerting path by sending a test message or triggering a controlled notification. Fifth, store credentials in a shared, access-controlled location that is not an individual's private notebook. Sixth, write a one-paragraph recovery note describing who acts first, where the documents are, and how to reach that person when normal hours are over.
When you finish, read the log aloud to someone who did not build the site. Their questions will expose assumptions you stopped noticing. Then schedule the next review. Quarterly works for most small businesses, and any change to hosting, staff, or vendors should trigger an update.