Downtime cost calculator

What this calculation does and does not include

The figure above is direct lost revenue: the sales that would have happened during the hours you were unavailable, assuming revenue is spread evenly across the month. It is deliberately simple, which makes it useful as a floor rather than a forecast.

The real cost is higher, and the parts it omits are often the larger ones.

• Engineering timeSeveral people pulled off planned work for the incident, plus the follow-up and postmortem.
• Support loadA ticket spike that continues for days after the outage itself is resolved.
• Churn and trustCustomers who do not complain and do not come back. The most expensive category and the hardest to measure.
• SLA creditsContractual refunds owed to enterprise customers, which can dwarf the direct revenue loss.

How the estimate is calculated

The calculator spreads your monthly revenue evenly over a 30-day month (720 hours) to get an average revenue per hour, then multiplies it by the outage hours you expect in a year:

annual cost = (monthly revenue ÷ 720) × annual outage hours

With the starting values, $50,000 a month is about $69 an hour, and 4 hours of downtime a year comes to about $278. In rupees, ₹40,00,000 a month is about ₹5,556 an hour, or about ₹22,222 for 4 hours. Small numbers like these are common for a single outage at average traffic, which is exactly why the omitted costs below matter.

A worked example with peaks

Suppose a store earns $200,000 a month and had three incidents last year: two of 40 minutes at quiet times and one of 2 hours during a sale, when traffic runs at three times the average. The calculator, given 3 hours and 20 minutes (enter 3), says about $833. Weighting the sale hours properly gives a different picture: the quiet incidents cost about 1.3 hours × $278 = $370, and the sale incident 2 hours × $278 × 3 = $1,667, roughly $2,000 in total before support, churn and engineering time. Use the calculator for the baseline, then weight the hours you know were busy.

For context, 4 hours a year is about 99.95% uptime, and 99.9% allows almost 9 hours a year. The SLA uptime calculator converts any target into hours, and what uptime really measures explains why the same percentage can mean different things.

Where outage hours come from

Every outage has two parts: the time before anyone knows (detection) and the time to fix it (repair). Multiply the number of incidents in a year by their average detection plus repair time and you have your annual outage hours. Twelve incidents at 20 minutes each is 4 hours. The guide to MTTR and MTTD covers how to measure both, and the MTTR and MTBF calculator works them out from your incident list.

Using the number

The practical purpose of this calculation is comparison. Once you know that an hour of downtime costs a specific amount, questions about whether to invest in redundancy, faster detection, or better on-call coverage stop being matters of opinion.

Detection speed is usually the cheapest lever. Cutting your average detection time from five minutes to one removes four minutes from every incident for the entire year, at a fraction of the cost of infrastructure redundancy.

On average a failure waits half a check interval before the next check sees it, so the interval you choose is part of every outage. The check interval planner shows the trade-off, and SutramX uptime monitoring confirms a failure from more than one region on paid plans before it alerts you, so faster checks do not mean more false alarms. See how alerting works for the path from a failed check to a message.

Frequently asked questions