How it works
Downtime cost has two independent components that this calculator sums. The first is revenue you cannot earn while systems are offline. The second is employee time paid for but wasted when staff cannot do their jobs. Modelling them separately keeps the number defensible: each half rests on figures your finance team already owns.
The inputs:
- Annual Revenue: total top-line revenue for the year, used to derive an average revenue-per-hour rate.
- Business Hours per Year, the denominator for that rate. Use 8,760 (24×7) if revenue accrues around the clock, or 2,080 if it only accrues during staffed business hours.
- Employees Affected, headcount unable to work during the outage.
- Avg Loaded Hourly Cost: fully burdened cost per employee-hour: salary plus benefits, tax and overhead, typically 1.25–1.4× base pay.
- Productivity Loss While Down, the share of affected work that genuinely stops. Rarely a clean 100%; staff often shift to other tasks.
- Outage Duration, length of the incident in hours.
productivityLoss = employees × loadedHourlyCost × duration × ( productivityLoss% ÷ 100 )
totalCost = revenueLoss + productivityLoss
Cost per hour is totalCost ÷ duration; cost per minute divides that by 60.
Worked example. A firm with $50M annual revenue running 24×7 (8,760 hours), with 200 employees at a $65 loaded hourly rate, fully stopped (100%) for a 4-hour outage: revenue loss = (50,000,000 ÷ 8,760) × 4 ≈ $22,831; productivity loss = 200 × 65 × 4 × 1.0 = $52,000. Total ≈ $74,831, about $18,708 per hour, or $312 per minute.
Benchmarks & reference points
These are exact or definitional reference points, not survey statistics. Use them to sense-check inputs and to pair the cost figure with the resilience targets a board expects to see.
| Reference | Value / definition |
|---|---|
| 99% ("two nines") uptime | ~3d 15h downtime/year |
| 99.9% ("three nines") | ~8h 46m/year |
| 99.99% ("four nines") | ~52m 36s/year |
| 99.999% ("five nines") | ~5m 15s/year |
| RTO (Recovery Time Objective) | Target max time to restore a service; tiers often run mission-critical <1h, important hours, deferrable a day+ |
| RPO (Recovery Point Objective) | Target max data loss window; tiers often run near-zero, minutes, or hours by criticality |
| Single Loss Expectancy | SLE = AssetValue × ExposureFactor |
| Annualized Loss Expectancy | ALE = SLE × ARO |
| Availability from reliability | A = MTBF ÷ (MTBF + MTTR) |
Using this in the boardroom
A single per-hour figure is the most portable output here, it converts an abstract technical risk into a rate a board already reasons in. Present it beside the availability target of the affected service: if one hour costs the example firm ~$18,700, then the gap between three nines (~9 hours/year) and four nines (~53 minutes/year) is worth roughly $150k of annual exposure, which is the honest budget envelope for the HA or DR investment you are proposing.
Pair the number with two things: an annualized view (multiply a representative outage by a plausible frequency, the ARO in the table above) and a short list of the hidden costs this model deliberately excludes, reputational damage, regulatory penalties, customer churn, and overtime recovery effort. Naming those exclusions builds credibility rather than undermining it. The most common pitfall is treating 100% productivity loss and 24×7 revenue as universal defaults; both inflate the figure and invite challenge, so tune them to how the specific service actually behaves.
The one-line takeaway
Downtime is a rate, not an event. Express it per hour, multiply by the availability gap you are closing, and the resilience business case sizes itself.
Frequently asked questions
Should I use 8,760 or 2,080 business hours?
Use 8,760 (24×7) when revenue accrues continuously, such as e-commerce or SaaS. Use 2,080 (roughly a staffed work-year) when revenue only lands during business hours, which raises the per-hour revenue rate and better reflects a daytime outage.
What is a "loaded" hourly cost and how do I estimate it?
Loaded cost is fully burdened: base pay plus benefits, payroll tax, and overhead. A common shortcut is base salary ÷ 2,080, then multiply by 1.25–1.4. Finance can usually supply a blended figure directly.
Why is productivity loss not always 100%?
When one system fails, staff frequently pivot to email, offline tasks, or workarounds rather than stopping entirely. Setting the loss below 100% reflects that partial capacity and produces a more defensible estimate.
Does this include reputational or regulatory costs?
No. This model captures direct revenue and productivity loss only. Reputational damage, customer churn, contractual SLA penalties, and regulatory fines are real but organization-specific, so they should be added separately as qualitative or scenario-based figures.
How does this relate to RTO and RPO?
The per-hour cost is what makes an RTO target economically legible: it tells you what each hour of recovery time is worth, which in turn justifies the investment needed to shorten RTO or tighten RPO for a given service.
These outputs are directional estimates for planning and business-case discussion only. They depend entirely on the assumptions you enter and exclude hidden costs such as reputational damage, regulatory penalties, and customer churn. This is not financial, legal, or investment advice; validate any figure with your own finance and risk functions before acting on it.