Website Reliability Planning: Writing Down the Recovery Time You Can Actually Live With

1 Matrix Tech editorial ·

Ablauf DHCP Snooping
Illustrative image. Rr 750 · CC BY-SA 4.0 · Cropped and resized. Image source

Most small businesses discuss website outages in vague terms. People say the site should always be up, or that it should come back quickly. Those phrases feel reasonable until a real outage arrives and nobody agrees on what quickly means. A more useful approach is to decide, in advance and in writing, how long your business can tolerate the site being unavailable and what kinds of disruption matter most. This article walks through a practical way to set that expectation, along with the questions to put to anyone who helps keep your web presence running.

Start With the Cost of Silence

Before you think about technology, think about what your website actually does for your business in a typical week. For some companies, the site is a brochure that customers check before calling. For others, it takes inquiries, displays a booking calendar, or passes customers to a phone line or a shop. Each role carries a different cost when the site is unreachable. A brochure site going dark for a day may cause mild annoyance and a few lost impressions. An intake form that silently fails for a weekend may cost real leads.

Write down the three or four ways customers reach you through the web. Next to each, note what happens to your business if that path is unavailable for one hour, one day, and one week. This exercise does not require exact numbers. Rough categories such as minor, noticeable, or serious are enough to shape your planning. The point is to replace the phrase the site should always be up with a set of specific consequences you can discuss with other people.

Define Recovery Expectations in Plain Terms

Once you know what the site is for, you can describe the recovery expectation you want. Two ideas help here. The first is how long the site can stay down before the business feels it in a way that matters. The second is how much older content or data you can tolerate if you must restore from a previous copy. Planners sometimes call these the outage tolerance and the data loss tolerance, but you do not need the jargon. Simply write two sentences: The website can be unavailable for up to a certain number of hours before we need to act on it, and if we ever restore it from a backup, we can afford to lose up to a certain amount of recent changes.

Be honest rather than aspirational. A small law office, a regional repair shop, and an online store will have very different answers. Your answers should reflect how you operate, not how a perfect setup would look. Keep the statements short enough that a new employee could read them and understand the expectation.

Questions to Ask Anyone Who Supports Your Site

Whether your web help comes from an internal staff member, a freelancer, or an outside technology firm, you should be able to put specific questions to them and get clear answers. Ask who is responsible for responding when the site is reported down, and what the expected first response looks like. Ask how the site is checked for availability, and who is told when something appears wrong. Ask where the site's files, database, and configuration live, and whether anyone besides the current contact has the access needed to manage them.

Ask what happens to your domain name registration, DNS settings, and email records if the person who set them up leaves. Ask what the process would be for restoring the site to an earlier state, and how long that typically takes. Ask whether that process has ever been practiced, and if so, what was learned. If an answer is vague, that is information too. Write the answers down, including the vague ones, so you can return to them later.

A Simple Checklist for Your Reliability Notes

Keep a single page that captures your planning decisions. Include the three or four website functions you identified, your outage tolerance in plain hours or days, and your data loss tolerance in plain terms. List the name and contact method for the person who responds first when the site fails, and a second name for when the first is unavailable. Record where your domain registrar account is held, who controls DNS, and when the domain renewal date falls. Note the date the page was last reviewed.

Review this page every few months, and after any change to your site, hosting arrangement, or staff. Compare what the page says with what actually happens. If a contact has changed roles, update the page the same day. A reliability plan is only useful if it reflects the current arrangement, so treat the page as a living record rather than a document you write once and file away.

Turning Notes Into Decisions

The final step is to use your notes to make choices. If your outage tolerance is a few hours but your only contact is unreachable on weekends, you have found a gap to discuss with your support arrangement. If your data loss tolerance is essentially zero but you have no clear description of how past changes are preserved, you have found a question to put to your provider. The value of this process is not perfection. It is the conversation it forces, and the written record that lets you hold those conversations later.

Small businesses that do this work often find that the biggest reliability risks are not exotic. They are ordinary matters like an unclaimed renewal notice, a single person who knows the login details, or an assumption that someone else is watching the site. Writing down your expectations makes those assumptions visible, and visible assumptions are far easier to correct before a failure than after.