Cost of Downtime Calculator

Estimate the cost of business interruption from a breach, ransomware or outage: revenue per hour × hours of downtime × a productivity factor, plus a one-off recovery cost. The productivity factor scales the loss for partial operation, and the recovery field captures the fixed cost of restoring systems on top of the lost output. Numbers update as you type. Benchmarks as of Jun 25, 2026 — sources; every figure is editable.

Lost output during the outage
1.0 = fully offline; 0.5 = running at half capacity.
One-off recovery
Restore/rebuild labor, hardware, overtime — paid once, not per hour.
Estimated cost of downtime: $240,000 = $10,000/hr × 24 hrs × 1.00 + $0 recovery.
Lost output$240,000
Recovery$0
Total$240,000
Per hour$10,000
The downtime cost, step by step
StepValue
Revenue per hour$10,000
× Hours of downtime24
× Productivity factor1.00
= Lost output$240,000
+ Recovery cost (one-off)$0
= Total cost of downtime$240,000
Formula.
Cost of downtime = revenue per hour × hours × productivity factor + recovery
Default: $10,000 × 24 × 1.00 + $0 = $240,000
The productivity factor multiplies the lost-output term only; the recovery cost is added once.

How it works

When a breach, ransomware attack or system failure takes you offline, the most immediate and tangible cost is the value of the business you cannot do while you are down. This calculator isolates that business-interruption cost and builds it from three intuitive quantities: how much value your operations produce in an hour, how long the outage lasts, and how completely it stops you — with a separate line for the one-off cost of putting things back together. Keeping these terms explicit makes the estimate easy to challenge and easy to refine as better information arrives during an incident.

The first input is revenue per hour. This is the value the affected operations generate in a typical hour of business. The cleanest way to estimate it is to divide annual revenue by the number of hours the business actually operates in a year: a round-the-clock online operation divides by 8,760 hours, while a firm trading a standard 40-hour week divides by roughly 2,080. If you want a more conservative figure, use gross margin rather than top-line revenue, since some variable costs disappear while you are not trading. Whichever you choose, the field is editable, so you can drop in the number that best represents what the downed systems are really worth per hour.

The second input is the hours of downtime — the duration of the outage from the moment operations stop to the moment they are fully restored. The third is the productivity factor, which is what makes this model realistic rather than naive. A complete outage, where nothing can be done, has a productivity factor of 1.0: you lose the full hourly value for every hour. But many incidents only degrade operations. If you can still serve customers at half capacity through manual workarounds, a backup site, or partially functioning systems, the factor is 0.5 and you lose only half the hourly value. The factor can even exceed 1.0 when an outage triggers losses larger than the bare revenue — contractual penalty clauses, service-level credits, expensive overtime, or lasting damage to customer goodwill. Because it multiplies the lost-output term only, the productivity factor scales the per-hour bleed without distorting the fixed recovery cost.

That brings us to recovery, the one-off cost of getting back to normal. Unlike lost output, recovery does not scale with the number of hours you were down; it is a fixed bill you pay once. It covers emergency IT and forensic labor, rebuilding or restoring systems from backups, replacement hardware, and the overtime needed to clear the backlog that built up while you were offline. Because it behaves so differently from the per-hour loss, the model adds it at the end rather than folding it into the multiplication. Setting it to zero gives you the pure lost-output figure; populating it gives you the all-in cost of the interruption.

Two things are worth remembering about the result. First, this is the business-interruption cost only — it deliberately excludes notification, legal, regulatory and reputational costs, which a full breach also generates. For the complete figure, use the data breach cost estimator; when the downtime is caused by ransomware, the ransomware cost calculator bundles downtime with ransom and recovery. Second, a single downtime cost is a one-incident figure. To convert it into an annual risk you can budget against, treat it as a single loss expectancy and run it through the annual loss expectancy calculator alongside your breach probability.

A worked example

Consider an online business that earns about $10,000 an hour and is knocked completely offline for a full day — 24 hours — by a ransomware incident, with the recovery work handled inside an existing IT retainer so there is no separate recovery bill to add yet.

  • Lost output = $10,000 × 24 hrs × 1.00 (fully offline) = $240,000
  • Recovery cost = $0 (none added separately)
  • Total cost of downtime = $240,000 + $0 = $240,000

Now make it realistic. Suppose the business could actually limp along at half capacity using a manual order process, so the productivity factor is 0.5 rather than 1.0 — the lost output halves to $120,000. Then add a $40,000 recovery bill for emergency restoration and overtime, and the total becomes $160,000. Each adjustment is visible and defensible. To place this downtime figure inside the full incident cost, carry it into the ransomware cost calculator; to turn it into an annual expected loss, use it as the single loss expectancy in the annual loss expectancy calculator.

Frequently asked questions

How do you calculate the cost of downtime?

The core formula is revenue per hour × hours of downtime × a productivity factor, plus any one-off recovery cost. For the default scenario — $10,000 an hour, 24 hours fully offline, no separate recovery bill — the cost is $240,000. The productivity factor lets you model partial operation, and the recovery field captures the cost of restoring systems on top of the lost output.

What is revenue per hour, and how do I estimate it?

It is the revenue (or, more strictly, the gross margin) your business generates in a typical operating hour. A quick estimate is annual revenue ÷ annual operating hours — for a business open around the clock that is revenue ÷ 8,760, while for one trading 40 hours a week it is revenue ÷ roughly 2,080. Use the figure that best reflects the value the affected systems actually produce per hour.

What does the productivity factor do?

The productivity factor scales the loss for the share of operations that the outage actually stops. Set it to 1.0 when the business is completely offline and producing nothing. Set it below 1.0 — say 0.5 — when you can still run at half capacity (manual workarounds, partial systems, a backup site). You can even set it above 1.0 to capture knock-on losses such as penalty clauses, overtime or lost goodwill that exceed the bare revenue figure. It multiplies the lost-revenue term only; it does not touch the recovery cost.

What goes in the recovery cost?

Recovery is the one-off, fixed cost of getting back to normal that you pay regardless of how many hours you were down: emergency IT and forensic labor, rebuilding or restoring systems, replacement hardware, overtime to clear the backlog. It is added once at the end rather than multiplied by the hours, because it is not a per-hour loss. Leaving it at zero gives you the pure lost-output figure.

How is this different from total breach cost?

Downtime cost is just the business-interruption slice — the value of lost operations during the outage. A full breach also generates detection and forensics, notification, legal and regulatory cost, and post-breach remediation. Use the data breach cost estimator for the complete picture, the ransomware cost calculator when downtime is driven by ransomware, and the annual loss expectancy calculator to turn a single downtime cost into an annual risk figure.

Disclaimer. BreachCostLab provides cost and risk estimates for informational purposes only, based on published industry benchmarks (e.g. IBM/Ponemon Cost of a Data Breach, Verizon DBIR) and publicly available statutory figures as of the verification date shown (Jun 25, 2026). These figures are estimates for planning, not a prediction of the cost of any specific incident, and are not legal, financial, insurance, or compliance advice. Actual breach costs vary widely; for regulatory obligations consult qualified counsel. Always verify current figures with the cited sources.