Website Reliability Planning: Writing Down the Failure Modes You Haven't Tested
Most small business websites fail in ways nobody planned for. The site works for months, then a renewal lapses, a form stops sending mail, or a plugin update breaks the checkout page, and the first person to notice is a customer. Reliability planning does not require special equipment or a large budget. It requires a written list of what could go wrong, who would notice, and what the first hour of a response should look like. This article walks through a method for building that list and turning it into a plan you can actually use.
Start With the Symptoms, Not the Systems
Many teams begin reliability planning by listing technical components: hosting, domain, email, forms, analytics. That inventory matters, but it is easier to act on if you start from the symptoms a customer or staff member would see. Write down the outcomes that would hurt the business if they stopped working. Examples include the homepage not loading, the contact form silently dropping messages, quote requests not reaching the sales inbox, or the site showing an expired certificate warning.
For each symptom, write one sentence describing how a person would discover it. Someone might find out because a customer emails, because a staff member cannot log in, or because a search result shows an error. The discovery path tells you where your monitoring gap is. If the only way you learn about a broken form is a customer complaint, that is a failure mode with no early warning.
Keep the list short at first. Ten symptoms that you have thought through are more useful than fifty that you have not examined. You can expand the list after the first pass.
Trace the Dependencies Behind Each Symptom
Once you have a symptom list, ask what each one depends on. A contact form may depend on a form service, a mail provider, a domain's DNS records, and a notification address that belongs to one employee. A product page may depend on an image host and a payment widget from a third party. Drawing these links on paper is enough. The goal is to see chains, because a single expiring item can take down several symptoms at once.
Pay particular attention to renewals and credentials. Domain registrations, SSL certificates, hosting plans, and software licenses all have dates attached to them. Note who receives the renewal reminders and whether those reminders go to an inbox that someone checks. Renewal dates are among the most common causes of avoidable downtime, and they are easy to record in a shared calendar.
Also note where administrative access lives. If only one person can log into the domain registrar or the hosting control panel, that person is a single point of failure, regardless of how capable the hosting platform is.
Assign Owners and Write Down Response Assumptions
A reliability plan is only useful if someone is responsible for each item. For every symptom, name a primary owner and a backup. The owner does not need to perform every fix personally, but they should know who to contact and what decisions they can make without asking permission. A plan that says "the team will handle it" usually means nobody will.
Next, write down the assumptions your plan rests on. Typical assumptions include: someone will read the renewal emails within a week, the backup contact is available outside business hours, the hosting provider's status page will be checked during an incident, and staff know where the credentials are stored. Each assumption should be stated plainly so it can be tested. An assumption you cannot describe is one you cannot verify.
Ask a set of direct questions. Who answers the phone at two in the morning if the site goes down during a promotion? Who can approve spending on an emergency fix? What is the longest acceptable period for a broken contact form before someone is notified? Answers to these questions are the substance of your plan. If you cannot answer them, the plan is not finished.
A Practical Checklist for the First Planning Session
Use the following checklist as a working document, filling in answers in plain language rather than polished phrasing. First, list the five to ten outcomes that would hurt the business if they failed. Second, for each outcome, record how it would be discovered and by whom. Third, list the services and renewal dates it depends on, including domain, DNS, email, forms, and hosting. Fourth, name a primary and backup owner for each. Fifth, write down the assumptions your response relies on and mark any you have not verified.
When you finish, compare the list against your actual setup. Check whether the renewal contacts are current, whether the backup owner still works with you, and whether the credentials needed for recovery are stored somewhere the backup can reach. Put a review date on the calendar, perhaps every quarter, so the plan does not quietly go stale.
A reliability plan does not prevent every outage. Its value is that it makes the gaps visible before a customer finds them. Writing down the failure modes you have not tested is the first step toward testing them.