Recovery Path Inventory: Mapping How Your Site Gets Back Online
Most small site teams can describe how their site works when everything is healthy. Far fewer can describe how it comes back after something breaks. A recovery path inventory is a plain-language record of every route your site can take from failure back to normal service. It does not require special tools. It requires honesty about what you control, what you depend on, and what you would need to do at an uncomfortable hour. This article walks through a method for building that inventory, the questions that expose gaps, and a checklist you can apply to any hosting arrangement, whether shared hosting, managed WordPress, or a VPS you administer yourself.
Start With the Failure, Not the Architecture
Many teams begin a reliability review by drawing diagrams of servers, databases, and third-party services. Diagrams are useful, but they organize the system by how it was built rather than by how it fails. A better starting point is a short list of realistic failure scenarios. Examples include a bad plugin or code deployment that breaks the homepage, an expired certificate that causes browsers to block the site, a corrupted database table, an account lockout after a staff member leaves, and a billing problem that suspends the service.
For each scenario, write one sentence describing what a visitor would see and one sentence describing who would notice first. This keeps the exercise grounded. A certificate problem and a broken checkout form produce very different symptoms, and they usually require different people and different recovery steps.
Trace Each Failure to a Recovery Route
For every scenario, ask a single question: what is the first concrete action someone would take to restore service? Write the answer as a specific step rather than a general intention. 'Contact support' is a step, but it is not a recovery path unless you know the channel, the expected response, and what information support will need from you. 'Roll back the last deployment' is a recovery path only if you know where the previous version is stored and who has permission to restore it.
Pay attention to recovery routes that depend on a single person. If the only person who knows how to reach the hosting control panel is unavailable, the route is fragile regardless of how well the platform performs. Note these dependencies explicitly. They are often the most valuable findings in the entire exercise.
Ask Questions Your Provider Must Answer
Some recovery routes depend on what your hosting provider offers, and you should verify those details rather than assume them. Before relying on any route, check the provider's own documentation and terms. Useful questions include: What restore options are included with my plan, and how are they accessed? Who is responsible for data recovery, and what does my account agreement actually say? How do I request help during an incident, and through which channels? What information will I need to provide to support? Are there any costs or time limits attached to restore requests?
Write the answers down with the date you checked them. Plans change. A recovery path you verified two years ago may no longer match the current service description. If a provider's documentation does not answer a question, treat that as an open item to resolve before you need the answer during an outage.
Separate What You Control From What You Only Hope For
Each recovery route should be labeled according to who can execute it. Some routes are entirely within your team's control, such as editing site content, reverting a theme file you keep in version control, or updating DNS records you manage. Others require the provider, such as restoring infrastructure or escalating a platform-level fault. A third category depends on third parties, such as a payment processor or an email delivery service.
The distinction matters because it determines where your effort should go. Routes you control deserve documentation and rehearsal. Routes that depend on a provider deserve a clear escalation process and an honest assessment of response expectations. Routes that depend on third parties deserve a fallback plan, even a simple one such as a temporary notice page or an alternative contact method for customers.
A Practical Checklist for Your Inventory
Use the following checklist to review your inventory. First, confirm that each failure scenario has at least one named recovery route. Second, confirm that each route has a specific first step written in plain language. Third, confirm that each route has an identified owner and a backup owner. Fourth, verify that credentials for every route are stored where more than one authorized person can reach them. Fifth, check whether any route requires access that would be lost if a staff member left tomorrow. Sixth, note the date of your last verification of provider-dependent details. Seventh, record any route you have never tested, and schedule a low-risk test or a tabletop walkthrough for it.
Keep the inventory short enough that someone will actually read it during an incident. Five to ten scenarios with clear routes are more useful than a sprawling document nobody opens. Review the inventory whenever you change hosting plans, add a major integration, or change who administers the account. A recovery path inventory is not a one-time deliverable. It is a living record that becomes more valuable each time you check it against reality.