Disaster recovery budget proposals usually fail in the same way. Engineering presents a redundant architecture, leadership asks what happens if we do nothing, and the answer is that the system might be down for a few hours. A few hours does not sound severe, and the proposal slips to next year. The problem is not the architecture, it is the unit: engineering speaks in hours, finance listens in money, and nobody does the conversion.
This article shows how to build that conversion. We do not offer an industry figure, because an external average says nothing about your business and will be dismissed in the first fifteen minutes of the meeting. Every part of the model below uses variables you take from your own books.
Why an external average is unusable
The cost of an hour of downtime varies enormously between organisations, and within one organisation depending on when the outage lands. A sales system down at peak on the last day of the month and the same system down at four in the morning on a Sunday produce numbers that differ by multiples. A single external figure cannot reflect your revenue mix, your degree of automation, or the penalty clauses in your contracts.
More importantly, a number whose origin you cannot explain damages the credibility of the whole proposal. The finance director will ask where it came from, and if the answer is a report found online, the rest of your presentation will not be heard.
Components of the cost of an outage hour
Lost revenue
Start from average revenue per hour for the affected channel in the window under consideration, call it R. Take twelve months of revenue for that channel, divide by actual operating hours, then adjust with a peak factor.
The subtlety is that not all of this revenue disappears. Some customers return once the system is back. Call k the recapture rate, so genuinely lost revenue is R times one minus k. For essential goods k tends to be high; for impulse purchases or markets with easy substitutes it is low. If you have had an incident before, estimate k from revenue in the days that followed rather than guessing.
Idle labour cost
While the system is down, staff who depend on it are still paid but produce nothing. Call L the number of affected staff, w the average fully loaded hourly cost, and p the share of their work that is genuinely blocked. The cost is L times w times p. The p factor matters: a warehouse worker without system access may still do other work, a contact centre agent largely cannot.
Recovery labour cost
This is the additional effort to restore service and clean up afterwards: out-of-hours engineering time, hourly vendor assistance, and above all post-incident data reconciliation. Reconciliation is routinely forgotten and often runs longer than the outage itself, because in-flight transactions have to be checked by hand. Add the knock-on cost too: work that was scheduled for those engineers during the following days does not happen, so the delivery slippage caused by an outage belongs in this line as well.
Contractual penalties and service credits
If you have service level commitments with customers, reread the clauses and calculate to the contract formula. For enterprise agreements this line can exceed direct lost revenue. Include related obligations too, such as partner compensation or the cost of processing claims.
Customer churn and reputation
This is the largest term and the hardest to quantify, and the honest treatment is to say so rather than assign it an invented value. A workable approach: estimate the number of customers at risk of leaving after a prolonged outage, multiply by the customer lifetime value your commercial team already maintains, and present it as a wide range explicitly labelled as an estimate. If no lifetime value exists, keep this term qualitative and present it as an unpriced risk rather than fabricating a figure.
Assembling the formula
Cost of one outage hour in a given window:
Hourly cost equals R times one minus k, plus L times w times p, plus hourly recovery labour, plus hourly contractual penalties, plus the churn term presented separately as a range.
| Variable | Meaning | Source |
|---|---|---|
| R | Hourly revenue of the affected channel | Twelve-month revenue divided by operating hours |
| k | Share of revenue recaptured after recovery | Revenue data following prior incidents |
| L | Number of staff whose work is blocked | HR, by department dependent on the system |
| w | Average fully loaded hourly cost | Finance, salary plus associated costs |
| p | Share of work fully blocked | Estimated by business unit leads |
| Penalties | Service credits and compensation | Clauses in customer contracts |
Not every hour is the same
A model with a single number is easy to argue against. Calculate at least three scenarios: peak hour in peak season, ordinary working hours, and out of hours. Also separate two failure modes: full outage and partial degradation. Degradation usually lasts longer and can cost more in total, even though it feels less severe at the time.
Break cost down by duration too, rather than multiplying linearly. Thirty minutes is largely absorbed; six hours starts triggering contract clauses, generating complaints and creating substantial reconciliation work. The loss curve against time usually steepens rather than staying flat.
From downtime cost to recovery objectives
Once you have an hourly figure, the DR budget becomes a comparison rather than a matter of instinct. Two steps:
- Estimate annual expected loss: probability of an incident in a year, times expected duration, times hourly cost, summed across scenarios. Take probability from your own incident history and your providers’ history, and present it as a range.
- Compare that expected loss against the annual cost of each recovery capability tier. Each lower recovery time objective costs more, and the loss it avoids typically shrinks. The sensible point is where the marginal cost of lowering the objective exceeds the loss it avoids.
Framed this way, the conversation moves from whether to buy insurance to how much insurance to buy, which is a decision leadership is used to making.
The same model also tells you where not to spend. Not every system deserves the same recovery objective, and applying one target across the estate is the fastest way to make a DR budget look unaffordable. Run the calculation per system, or per group of systems that share a dependency, and you will usually find a small number of services carrying most of the hourly cost. Those justify aggressive recovery targets; the rest can sit on a slower, cheaper tier without materially changing expected loss. Presenting that tiering alongside the numbers also signals to leadership that the proposal is a considered allocation rather than a request for everything at once.
Validate with drills
The recovery time in a design document is an assumption until it has been rehearsed. Measure real recovery time in a scripted drill, including the non-technical steps: internal communication, the decision to fail over, and data reconciliation after service returns. The gap between designed and measured recovery time is one of the most persuasive facts you can bring to a budget meeting.
Mistakes that sink the proposal
- Presenting a single number to the nearest unit, with no range and no stated assumptions.
- Omitting the recapture factor k, inflating the loss in a way finance will catch.
- Assigning a specific value to reputational damage instead of presenting it as unpriced.
- Failing to express the proposed budget in the same time unit as the expected loss.
How HiTechCloud can help
HiTechCloud is an AWS partner and a Google Premier Partner and operates in-country infrastructure. We can help build a downtime cost model from your finance data, design recovery options at several recovery time and recovery point objectives so the costs can be compared, and run recovery drills with measured timings.
