Website Reliability Planning: Writing a Recovery Contact Sheet Before You Need It
When a website goes down, the first hour is often lost to a search for the right login, the right person, or the right account. Staff check email for a registrar notice, someone remembers a hosting password that was changed last year, and a marketing contractor is reached but does not know the current site setup. A recovery contact sheet is a short, written document that removes that guesswork. It does not make a website more reliable on its own, but it shortens the time between noticing a problem and deciding what to do about it. This article explains how to build one, what belongs on it, and which questions to answer while the site is working normally.
What a Recovery Contact Sheet Is For
A recovery contact sheet is a one-page or two-page reference that lists the people, accounts, and decisions connected to your website. Its purpose is to answer, in the middle of a stressful moment, the questions that otherwise take hours to resolve: who owns the domain, who can change the DNS settings, who manages the content, and who has the authority to approve a change or an expense.
The sheet is different from a full runbook. It does not explain every technical step. Instead, it points to the right people and locations, so that whoever is handling the incident can act quickly. Keep it short enough that someone can read it in two minutes while a visitor is waiting for a page to load.
The Questions the Sheet Should Answer
Start by writing down the questions that come up during an outage. Who is the primary contact for the domain registration, and what email address receives renewal notices? Who manages the web hosting account, and is that person employed by your business or by a vendor? Who edits the site content, and who approves changes to contact details, pricing pages, or forms? Who can be reached after hours, and by what method?
Add questions about decision rights. If a fix requires paying for a higher service tier, who signs off? If the site needs to be taken offline temporarily, who makes that call and who informs customers? Recording these answers in advance prevents a situation where a technician is ready to act but waits for approval from someone unreachable.
Finally, note where the credentials live without writing the credentials themselves on the sheet. A password manager entry name, a shared vault location, or a sealed envelope held by an owner is enough. The sheet tells people where to look, not what the password is.
A Practical Checklist for Building the Sheet
Use the following list as a working draft. Each item should be filled in while the website is functioning, when people can think clearly and confirm details.
First, record the domain name and the registrar, along with the email address used for renewal notices and the date the registration next expires. Second, record the hosting provider and the account owner, along with the name of the person who can approve a support request. Third, record the DNS host if it differs from the registrar or the hosting provider. Fourth, list the content editors and the people who approve changes. Fifth, list any third-party services the site depends on, such as a form tool, a payment page, or an email sender, and note who administers each one.
Sixth, record the escalation path: the first person to call, the backup person, and the method for reaching each. Seventh, note the decision owner for spending, taking the site offline, and communicating with customers. Eighth, record the date the sheet was last reviewed, and assign someone to review it on a regular schedule, such as every quarter or after any change in staff or vendors.
Comparing Ownership Models
Small businesses usually fall into one of three ownership patterns, and each has different risks. In the first pattern, the owner personally holds every account. This is simple but fragile, because a single person's absence can block all recovery work. In the second pattern, an outside vendor manages the hosting and DNS, while the business holds the registrar account. This splits responsibility, which is useful, but it means the business must know how to contact both parties and must confirm that the registrar account is in its own name rather than the vendor's.
In the third pattern, accounts are held in a shared location with more than one authorized person. This tends to be the most resilient, provided the shared location has clear access rules and the people named on the sheet actually know how to use it. When you write the sheet, identify which pattern you have now, not which one you intended to have. The gap between those two is often where recovery time gets lost.
Whichever model you use, ask a few direct questions. Is the registrar account in the business's name? Does more than one person have administrative access? Does anyone outside the business have the ability to remove access from the people named on the sheet? The answers will show where the sheet needs more detail.
Keeping the Sheet Useful Over Time
A recovery contact sheet decays quickly. Staff leave, vendors change, phone numbers move, and domain renewals roll over to new payment cards. Set a reminder to review the sheet on a fixed schedule, and also review it whenever someone with access joins or departs. During the review, test at least one contact: send a message to the after-hours number, or confirm that the renewal email reaches a monitored inbox.
Store the sheet where it can be reached during an outage. A copy kept only on the website itself is useless if the website is unavailable, so keep an offline or separately hosted copy that a designated person can open from a phone. Limit who can edit it, but make sure more than one person can read it. A sheet that only one employee can find is not a recovery plan.
The goal is not a perfect document. It is a short, current, and accessible record that lets your business answer, within minutes, who can act and who must approve. Build it while things are calm, and it will save time when they are not.