What the cost of downtime actually measures
The cost of downtime is the money a business loses because a system is unavailable, expressed as a rate you can multiply by time. It exists so you can compare two things that are otherwise incomparable: the price of an availability improvement, which arrives as an invoice, and the loss it prevents, which arrives as an absence.
Four components make up the number, and they behave differently. Lost revenue and idle payroll scale with the length of the outage. Recovery cost and contractual penalties are largely fixed per incident: rebuilding a failed node costs roughly the same whether the rebuild takes two hours or six, and most service-credit tables step rather than accrue continuously. Because two of the four buckets do not scale with time, a single headline “cost per hour” is an average over one particular outage length, not a physical constant. This calculator reports it as such, and shows you how it changes across durations from fifteen minutes to a day.
The framework is the one used in a business impact analysis, the step that NIST SP 800-34 Rev. 1 puts at the front of contingency planning. A BIA asks three questions of every system: what does an hour of its absence cost, how long can the business tolerate that absence, and how much data can it afford to lose. This tool answers the first. The second and third are the recovery time and recovery point objectives, and you can size them with the RPO and RTO data-loss calculator.
One thing the number is not: a prediction. It is a conditional statement — if this system is down for this long, under these assumptions about substitutability, the loss is this much. The assumptions are where the argument happens, so make them visible rather than burying them in a spreadsheet.
How the formula is built, term by term
Start with revenue. You do not know what any particular hour earns, so you spread the year evenly: revenue per hour is annual revenue divided by the hours in which revenue can actually be earned. That denominator matters more than anything else in the calculation. A 24/7 e-commerce platform earns across all 8,760 hours of the year, so a $25M business earns about $2,854 an hour. The same $25M through a system that only transacts during a 40-hour week is spread over roughly 2,080 hours, and each of those hours carries about $12,019. Using 8,760 for a business-hours system understates an in-hours outage by a factor of four.
Next, discount for substitution. Almost no outage stops all revenue. Customers phone instead of ordering online, orders queue and are captured later, a read-only cache keeps browsing alive while checkout fails. The revenue dependency percentage is your estimate of the share that is genuinely lost rather than deferred. Deferred revenue is not free — it arrives late and costs something to recapture — but counting it as lost is the single most common way these models get inflated.
The payroll term is headcount times fully loaded hourly cost times a productivity-loss factor. Use the loaded cost, not the salary: payroll tax, benefits, equipment and facilities typically add a substantial multiple to base pay, and your finance team already has the figure. The productivity factor accounts for the fact that people idled by an outage rarely do nothing. Setting it to 100% is a strong claim, and the calculator flags it when you do.
Recovery cost and penalties are added once. Recovery includes engineer overtime, emergency vendor support, replacement parts, and the often-forgotten cost of re-entering work that was captured on paper. Penalties come from your own contracts; read the credit table rather than assuming credits are proportional to downtime, because they usually step at thresholds.
Finally, multiply by your incident rate to get an annual figure. This is the number that belongs in a business case, because capital and operating costs are annual too. If your incident record does not go back far enough to give a rate, you can derive one from component reliability using the MTBF and MTTR availability calculator.
Worked example: a four-hour outage at a $25M business
Take the default scenario. A $25,000,000 business unit earns around the clock, so 8,760 revenue hours. Sixty per cent of its revenue depends on the system. 120 employees are idled at a fully loaded $55 an hour and lose 70% of their productivity. The outage lasts four hours and costs $12,000 in recovery labour and emergency vendor support. There are no SLA penalties, and the incident record shows three outages of this size a year.
- Revenue per hour. $25,000,000 ÷ 8,760 = $2,853.88 per hour.
- Revenue lost per hour. $2,853.88 × 0.60 = $1,712.33 per hour.
- Idle payroll per hour. 120 × $55 × 0.70 = $4,620.00 per hour.
- Cost rate. $1,712.33 + $4,620.00 = $6,332.33 per hour of downtime.
- Duration-driven cost. $6,332.33 × 4 = $25,329.32.
- Add the one-off cost. $25,329.32 + $12,000 = $37,329.32 for the incident.
- Cost per hour, as billed. $37,329.32 ÷ 4 = $9,332.33 per hour — higher than the $6,332.33 rate, because the fixed recovery cost is spread over only four hours.
- Cost per minute. $37,329.32 ÷ 240 = $155.54.
- Annual expected cost. $37,329.32 × 3 = $111,987.96.
- Break-even redundancy spend. If a proposed design removes 80% of that, $111,987.96 × 0.80 = $89,590.37 a year is the most it can cost and still pay for itself.
Notice step 7. The same failure over 24 hours would carry $6,332.33 × 24 + $12,000 = $164,975.92, which is $6,873.99 an hour. The longer the outage, the closer the billed hourly cost falls towards the underlying rate.
How to read the result, and what to do with it
Compare the annual figure with the annual cost of the fix, not with its purchase price. A $250,000 redundant cluster amortised over five years with $40,000 a year of support costs $90,000 a year. Against the $89,590 of avoided annual loss in the worked example, that is a coin toss, and the honest conclusion is that the case rests on something the model does not capture — reputational damage, regulatory exposure, or a single tail-risk outage far larger than the ones in your history.
Treat the per-minute figure with care. It is the right unit for arguing about detection and failover time, because those are measured in minutes, and it is the wrong unit for arguing about the whole outage, because the fixed recovery cost inflates it at short durations. If you are justifying faster monitoring, use the rate — the bracketed term with the fixed costs excluded — since faster detection shortens the duration-driven part and leaves the recovery bill largely intact.
Two sanity checks are worth running before you present the number. First, does the annual downtime cost exceed the total revenue attributable to the hours of downtime? If it does, your productivity term is doing more work than is credible, or you have double-counted staff who also appear in the revenue line. Second, does the implied availability match reality? Three four-hour outages a year is twelve hours of downtime, which is 99.863% availability — a figure you can cross-check against your own monitoring with the uptime and SLA downtime calculator. If the model's incident rate implies an availability your dashboards contradict, fix the input rather than the argument.
Finally, remember that this is an expected-value model. Expected values are the right basis for recurring, moderate incidents and a poor basis for rare catastrophic ones. For the latter, the relevant question is not the average annual loss but whether the business survives a single instance, which is a risk-appetite decision rather than an arithmetic one.
Downtime cost rate by business size
| Annual revenue | Revenue per hour | Revenue lost per hour (50%) | Idle payroll per hour | Cost rate per hour |
|---|---|---|---|---|
| $5,000,000 | $570.78 | $285.39 | $3,850.00 | $4,135.39 |
| $25,000,000 | $2,853.88 | $1,426.94 | $3,850.00 | $5,276.94 |
| $100,000,000 | $11,415.53 | $5,707.76 | $3,850.00 | $9,557.76 |
| $500,000,000 | $57,077.63 | $28,538.81 | $3,850.00 | $32,388.81 |
Every cell is the formula evaluated at the stated assumptions; substitute your own dependency and headcount rather than borrowing these rows. Note how payroll dominates at the small end and revenue dominates at the large end — that crossover is why two businesses with identical infrastructure can reach opposite conclusions about the same redundancy project.
Mistakes that make a downtime estimate indefensible
- Spreading revenue over 8,760 hours for a business-hours system. This understates an in-hours outage roughly four-fold. Divide by the hours in which the system can actually earn.
- Counting deferred revenue as lost revenue. An order placed by phone during the outage is not lost. Only the share that never arrives belongs in the revenue-dependency percentage.
- Using base salary instead of fully loaded cost. The loaded figure includes payroll tax, benefits and overhead, and it is the one your finance team recognises.
- Setting productivity loss to 100%. It asserts that no idled employee found anything else to do for the entire outage. If that is true, say why.
- Double-counting people who are also in the revenue line. If a sales team's idle hours are already reflected in the lost-revenue term, adding their payroll again inflates the total.
- Assuming SLA credits scale with duration. Most credit schedules step at thresholds — a breach at 99.9% and a breach at 99.0% can attract the same credit. Read the contract.
- Presenting a single scenario. A range across plausible durations and dependency assumptions survives scrutiny; a single point estimate invites an argument about one input.
- Ignoring partial degradation. A system running at 30% capacity is not up, and it is not down either. Model it as a shorter full outage of equivalent lost throughput.
What this model deliberately leaves out
Three real costs are absent because no defensible formula produces them: customer churn caused by the outage, brand and reputational damage, and regulatory or legal exposure. Any of them can exceed everything the calculator counts. Leave them out of the arithmetic and name them separately in your write-up as qualitative risk, so nobody can accuse the number of being padded. Where an outage has a known regulatory consequence with a published fine schedule, put that specific figure in the SLA penalty field, where it belongs and can be sourced.
Also absent is the cost of the mitigation itself: staff time consumed by failover testing, the complexity a redundant design adds, and the outages caused by that complexity. Comparing gross avoided loss against gross project cost is a fair first pass, not the final answer.
Where this sits among the other reliability numbers
Downtime cost is the money layer that sits on top of three engineering measurements. Availability tells you what fraction of time a service is usable; combine component figures into an end-to-end number with the series and redundancy availability calculator. Error budgets convert an availability target into a concrete allowance of failed requests, which the SLO error budget calculator quantifies. Mean time between failures and mean time to repair give you the incident rate and duration this calculator asks for.
The natural sibling in risk management is annualised loss expectancy, the product of a single loss expectancy and an annual rate of occurrence — the same structure as the annual figure here, applied to security incidents rather than availability incidents. The annualised loss expectancy calculator uses it directly, and a security team that already speaks ALE will recognise this model immediately.
If you are buying rather than building, the cost of downtime is also what makes a cloud provider's service credit look small. A credit is typically a percentage of the monthly fee for the affected service, which is bounded by what you pay them, whereas your loss is bounded by what you earn. Those two quantities are unrelated, and expecting a credit to make you whole is the most common misreading of a cloud SLA. Price the difference and either accept it, insure it, or engineer around it with multi-region redundancy whose cost you can size using the cloud VM monthly cost calculator.
Key terms
- Business impact analysis (BIA)
- The structured assessment that identifies which systems support which business functions, what an outage of each costs over time, and how long the business can operate without them. NIST SP 800-34 Rev. 1 places it before any contingency strategy is chosen.
- Fully loaded cost
- An employee's total cost to the business per paid hour — salary plus payroll taxes, benefits, equipment, facilities and administrative overhead. Always higher than the hourly equivalent of base salary.
- Revenue dependency
- The share of revenue that stops entirely during an outage rather than being deferred to another channel or a later time. Distinct from the share of revenue that merely passes through the system.
- Service credit
- A contractual refund, usually a percentage of the fee for the affected service, owed when availability falls below a committed level. Its size is set by the contract, not by your loss.
- Annualised loss expectancy
- The expected cost per year of a class of incident, calculated as the loss from one occurrence multiplied by the expected number of occurrences per year.