Website Reliability Planning: Who Answers the Phone at 2 A.M.?
Most small business websites go down at inconvenient times, and the outage itself is rarely the worst part. The worst part is the scramble that follows: nobody is sure who has the login, the domain renewal date is unknown, and the person who built the site is on vacation. Reliability planning is not only about technology. It is about answering a short list of human questions before the pressure arrives. This guide takes a different angle from typical checklists. Instead of asking what to back up, it asks who acts, in what order, and with what information in hand.
Start With a Contact Map, Not a Tool List
Before you think about any software, write down every person or account that can change or affect your website. That includes the person who registered the domain, whoever controls DNS records, the account holder for your hosting, the person who manages the email that receives customer inquiries, and anyone who publishes content. For each entry, record the name, the role, the account or login location, and the best way to reach that person outside business hours.
Many small businesses discover during this exercise that one employee holds the only copy of a critical login, or that a registrar notification goes to an inbox nobody checks. Those gaps are worth finding on a quiet Tuesday rather than during an outage.
Define Who Decides and Who Executes
An outage response usually fails at the decision point. Someone sees the site is down and must choose between waiting, contacting a provider, or making a change. Name one decision owner for each category of problem. The decision owner does not have to do the technical work, but they must be empowered to approve a support request, authorize spending on urgent help, or pause a planned change.
Separate the executor from the decision owner when possible. Write down which tasks the executor may perform without approval, such as restarting a service or confirming a status page, and which require sign-off, such as changing DNS records or migrating hosting.
Write an Escalation Path That Fits Your Size
An escalation path is a simple ordered sequence: first check, then first contact, then second contact, then the decision owner. A workable version for a small business might read like this. Step one, confirm the problem from two locations or devices so you know it is not a local network issue. Step two, check whether the problem is listed on any status information your providers publish. Step three, contact the person responsible for the affected system. Step four, if there is no response within a set period you chose in advance, contact the decision owner.
Set the waiting periods yourself and write them down. The point is not to hit a specific number but to prevent open-ended waiting where everyone assumes someone else is handling it.
Collect the Information You Will Need Before Asking for Help
When you contact any technical resource during an incident, the first ten minutes often go to gathering basic facts. You can save that time by keeping a single reference sheet. Include the domain name, the hosting provider and account identifier, the registrar, the DNS provider, the email platform, the date your domain registration expires, a description of recent changes such as plugin updates or design edits, and the exact error text or screenshot you saw.
Store this sheet somewhere the decision owner and at least one backup person can open it without relying on the affected website or its email. A printed copy in a file cabinet is a reasonable choice if nothing else is reliable.
A Short Checklist for Your Next Planning Session
Use the questions below as a working agenda. Who holds each login, and is that information stored in a shared, access-controlled location? Who receives renewal and billing notices for the domain and hosting, and who would notice if one went unpaid? What is the first step a non-technical staff member should take when the site appears broken? Who is authorized to contact outside support, and what spending limit applies without further approval? When was the last time someone other than the original builder tested logging in to the admin area? Which planned changes, such as redesigns or email changes, require a second person to review them first?
Answer these questions once, write the answers down, and review them each time your team changes. A website is a business asset, and planning who responds to its failures is as ordinary and necessary as planning who answers the phone.