Recovery Time Budgets: Deciding How Long Your Site Can Stay Down
Most small sites never write down how long they can afford to be unavailable. The question usually surfaces mid-outage, when someone asks whether they should wait, restore a backup, or move traffic somewhere else, and nobody has a shared answer. A recovery time budget is a simple written number, agreed in advance, that turns that argument into a checklist. It does not promise any particular performance from a hosting provider. It is a planning tool that helps a small team decide what matters, what to ask a vendor, and how to tell whether their current setup fits the job.
What a recovery time budget actually measures
A recovery time budget is the maximum period your site can be unavailable or degraded before the damage becomes unacceptable to you. Damage can mean lost orders, missed leads, support tickets from frustrated visitors, or a search engine crawl that returns errors. The number is different for a brochure site, a booking form, and an online store with active carts. Start by listing the functions visitors depend on, then estimate what an hour without each one would cost in plain terms: revenue, staff time, or reputation.
Keep the budget separate from any uptime percentage you have seen advertised. A percentage describes an average over a period and says nothing about how long a single incident lasts. Ten short interruptions and one six-hour interruption can produce similar averages but very different business outcomes. Write the budget as a duration, such as ninety minutes for the contact form or four hours for the whole site, and attach a short reason to each figure.
Separating functions by how much they matter
Not every part of a site deserves the same budget. A marketing page that is down for a morning may cost little, while a checkout path or login area may need a much shorter window. Group your site into three or four tiers. The top tier usually contains anything that takes money or personal information. The middle tier contains lead capture and account features. The bottom tier holds content pages, archives, and documentation.
For each tier, write a recovery target and an owner. The owner is the person who decides whether to wait or act. Without an owner, every incident becomes a committee meeting. A useful test is to imagine a Saturday evening outage and ask whether the person named would know what to do without calling someone else. If the answer is no, the target is not yet operational.
Translating budgets into hosting questions
Once you have targets, you can ask better questions before choosing or renewing a plan. Shared hosting, managed WordPress hosting, and VPS hosting divide responsibilities differently, and those differences affect how quickly you can recover. On a shared plan, the provider's environment hosts many sites at once, so you will rely heavily on their support channels and on whatever backup and restore features the plan describes. Managed WordPress plans typically concentrate on the application layer, so your questions should focus on what the provider handles and what you must handle yourself. A VPS gives more control, and with it more responsibility for the operating system, updates, and restoration steps.
Before committing money, ask the vendor to describe in writing the process for restoring a site, the expected steps a customer performs, and whether the provider documents any service levels. If a feature is not described in their materials, do not assume it exists. Ask directly, and record the answer with the date. Compare the stated answer against your budget: if your checkout budget is thirty minutes and the restore process described requires your staff to open a ticket and wait, the plan does not fit that tier, regardless of its price.
A short checklist for the first draft
Write down each site function and its tier. Assign a recovery target in minutes or hours and a named owner. Note the approximate cost of an hour of downtime in terms your team agrees on. List the steps someone would take to restore that function today, and mark any step that depends on a single person or an unwritten skill. Identify which steps depend on the hosting provider, and write the questions you need answered for each one. Store the document where the team can find it during an incident, not buried in a shared drive folder that requires a login that has expired.
Review the budget after any significant change: a new payment method, a redesigned form, a new plugin that touches logins, or a change in traffic patterns. Budgets that never change are usually budgets nobody reads.
Keeping the budget honest over time
A recovery time budget is valuable only if you test it. Walk through one function with a colleague and time how long the documented steps take, including the waiting. If the real figure is far larger than the target, you have learned something important: either the target is unrealistic or the setup needs work. Either conclusion is useful. Revisit the budget each quarter or after any incident, and record what changed. Over time, the document becomes a plain record of what your site needs, what your hosting plan actually delivers, and where the gap is. That record is worth more during a bad evening than any promise made in a sales page.