Put a number on an hour of downtime, then see what each recovery time objective is worth. Uses your figures, not a benchmark from a vendor report.
Revenue per hour is annual revenue divided by the hours you actually trade — not by all 8,760 hours in a year, unless you really are 24/7.
Overtime, contractors, replacement hardware
$4,460
8 hour outage: $40,677 all in
Cost if you recovered within each target, and what that saves against your 8-hour scenario.
| RTO | Cost | Saves |
|---|---|---|
| 1 hr | $9,460 | $31,217 |
| 2 hr | $13,919 | $26,758 |
| 4 hr | $22,838 | $17,838 |
| 8 hr | $40,677 | — |
| 1 day | $112,031 | — |
| 3 days | $326,092 | — |
An RPO is a data-loss budget. At 24 hours, an incident means redoing 1,200 employee-hours of work — about $54,000 on top of the outage itself.
Revenue per hour is annual revenue divided by operating hours — and the divisor matters. A business open 9-to-5 on weekdays trades about 2,080 hours a year, not 8,760, so using the calendar year understates hourly revenue by a factor of four.
Rarely 100%. If phone orders continue, or customers come back later, that revenue is delayed rather than lost. Be honest here — an inflated figure is the fastest way to get the whole estimate dismissed.
Headcount unable to work, their fully-loaded hourly cost (salary plus overhead, not just salary), and how much of their output is actually lost. People usually find something to do during an outage, so 50–80% is more defensible than 100%.
Overtime, contractors, expedited hardware. These are counted once because they do not scale with outage length, unlike the other two.
Cost per hour is the number that matters. The RTO table converts it into what each recovery target is worth, which is what turns "we should recover faster" into a figure someone can approve.
Totals depend on an outage length you are guessing at. Cost per hour does not, and it is the figure that prices a recovery time objective — which is usually the decision actually on the table.
They behave differently and get challenged differently. Splitting them means a disputed revenue assumption does not invalidate the productivity number, and vice versa.
Dividing annual revenue by 8,760 hours is the most common error in this calculation and it makes every result four times too small for a weekday business. Presets cover office hours, extended hours and 24/7.
Six recovery targets from one hour to three days, each with its cost and what it saves against your scenario. This is the output to put in front of a budget holder.
A recovery point objective is a data-loss budget, and "four hours of data" means little on its own. Converted into employee-hours of work to redo, and what that costs, it becomes concrete.
No "industry average cost per minute" anywhere. Published figures for that disagree by more than an order of magnitude and date quickly. Every number here comes from an input you provided, so you can defend all of it.
Justifying spend on resilience. Backup, replication and disaster recovery all cost money up front to avoid a cost that has not happened yet, which is a hard argument without arithmetic. Cost per hour makes it concrete: if an hour costs £4,000 and better recovery turns an eight-hour outage into a two-hour one, that is £24,000 avoided per incident, and the comparison against an annual licence becomes straightforward.
Setting an RTO that means something. Recovery time objectives are often chosen by feel — four hours because it sounds responsible. Pricing each target instead shows where the curve flattens: going from 24 hours to 8 usually saves a great deal, from 2 hours to 1 often saves little for a large jump in cost and complexity. That is where the RTO should land.
Post-incident reporting. After an outage, someone will ask what it cost. Having a documented method with visible assumptions produces a defensible figure rather than a guess, and being able to point at which input drives the total makes the follow-up conversation about fixing the right thing.
Prioritising which systems matter. Running the same numbers per system, with only the staff and revenue that depend on it, ranks them by cost per hour of unavailability. That ranking is what a recovery plan should be ordered by — and it is frequently not the order people assume.
A firm turning over 10 million a year, trading office hours (2,080 per year), where 60% of revenue depends on the affected system. 50 staff at a loaded cost of 45 per hour, losing 70% of their productivity. 5,000 of overtime and contractor time to recover. The outage lasts 8 hours.
Total: about 40,680. And the useful part — at 4,460 per hour, cutting the RTO from 8 hours to 2 saves roughly 26,760 on this single incident. That is the number to compare against the annual cost of whatever would deliver the shorter RTO.
Once you know your cost per hour, the rest is multiplication. Find your rate in the first column and read across for common outage lengths. Recovery costs are excluded because they do not scale with duration.
| Cost per hour | 1 hour | 4 hours | 8 hours | 24 hours | 3 days |
|---|---|---|---|---|---|
| 500 | 500 | 2,000 | 4,000 | 12,000 | 36,000 |
| 1,000 | 1,000 | 4,000 | 8,000 | 24,000 | 72,000 |
| 2,500 | 2,500 | 10,000 | 20,000 | 60,000 | 180,000 |
| 5,000 | 5,000 | 20,000 | 40,000 | 120,000 | 360,000 |
| 10,000 | 10,000 | 40,000 | 80,000 | 240,000 | 720,000 |
| 25,000 | 25,000 | 100,000 | 200,000 | 600,000 | 1,800,000 |
Currency-agnostic — the multiplication is the same whatever you are counting in. The gap between the 8-hour and 24-hour columns is the single strongest argument for a tested recovery process: it is the difference between a bad day and a bad quarter.
Add lost revenue to lost productivity, then add one-off recovery costs. Lost revenue is (annual revenue / operating hours) x the share of revenue that stops x outage hours. Lost productivity is people affected x their loaded hourly cost x the share of productivity lost x outage hours. The result is only as good as those four assumptions, which is why they should be visible rather than buried.
Only if you genuinely trade around the clock. A weekday, office-hours business operates about 2,080 hours a year, so dividing by 8,760 understates hourly revenue roughly fourfold — and an outage during trading hours costs the trading-hours rate, not the calendar average. Pick the divisor that matches when the outage would actually hurt.
Usually between 50% and 80%. A complete 100% loss implies nobody can do anything at all, which is rarely true — people catch up on other work, take calls, or work from local copies. Using 100% is the quickest way to have the whole estimate dismissed as inflated, and it is not necessary: the number is large enough at 70%.
RTO is how long recovery takes — a time budget. RPO is how much data you can afford to lose — a data budget, usually expressed as the interval between backups. They cost money in different ways: RTO costs you an outage, RPO costs you redoing work that was already done. A four-hour RPO with fifty people means up to 200 employee-hours to reconstruct, which this tool converts into a figure.
Because those figures are not usable. Published averages differ by more than an order of magnitude depending on who commissioned the study, which sectors were sampled and what was counted, and most are several years old. A number derived from your own revenue and headcount is both more accurate and more defensible than a citation someone can dismiss.
Take cost per hour, multiply by the difference between your current realistic recovery time and the one the investment would deliver, and compare that against its annual cost. Do it per incident and then per expected incidents per year. The RTO table does the first part for you. The argument that lands is not "downtime is expensive" but "this specific change avoids this specific amount".
Some do and some do not, which is why they are entered separately here. Replacement hardware and contractor callout are one-off. Overtime tends to scale with duration — if that is a large part of your figure, either fold it into the hourly productivity number or re-enter the one-off amount for each scenario you model.