The Real Cost of an Hour of Downtime (and How to Calculate Yours)

August 6, 2026

An hour of downtime is not an abstract risk. Splunk's 2026 research, produced with Oxford Economics, puts the average cost at $15,000 a minute, and ITIC's 2024 survey found that 41% of large enterprises lose between $1 million and $5 million in a single hour. Those figures come from global enterprises, which makes them useless for deciding whether your own outage was expensive. This post lays out the published numbers as a reference, then shows you how to calculate your own hourly cost in about 15 minutes using three inputs: revenue, payroll, and customer churn.

What the published figures actually say

Four numbers get quoted constantly, and they measure different things:

Read them the way they were produced. The Splunk figure is an average across Global 2000 companies, ITIC's is a self-report from enterprises, Gartner's has not been updated since 2014, and the Uptime Institute number counts data center operators rather than software companies. All of them exclude the cost of litigation, regulatory fines, and goodwill gestures. They are fine for a budget deck and nothing else. Your number comes from your own books, and it will almost certainly be smaller, and knowing it precisely is worth more than any of these averages.

What two real outages cost

Public incidents show how fast the math compounds when revenue and operations depend on the affected systems:

Facebook's outage ran from about 11:30 a.m. to just after 7 p.m. Eastern time. Fortune's estimate of $99.75 million is simply the company's average hourly revenue for the quarter, no modeling required. The CrowdStrike failure was a different class of event: a faulty update pushed to an estimated 8.5 million Windows devices, with Parametrix estimating $5.4 billion in direct losses and only 10% to 20% of that covered by cyber insurance. The lesson is not that your numbers need to be that big. It is that both estimates came from plain arithmetic on real revenue figures, which is exactly what you can do for your own company.

The three numbers you can actually calculate

Revenue at risk. Divide annual revenue by 8,760 hours, or monthly recurring revenue by 730. This is a floor: if your revenue concentrates in business hours, divide by the hours you actually sell into. For most B2B SaaS companies this is the smallest of the three numbers by a wide margin.

Payroll. Count the people who stop being productive while the system is down and multiply by their fully loaded hourly rate (base salary plus benefits and overhead, roughly 1.3x salary, divided by 2,080 working hours). Add the engineers who drop everything to fix it, and count their recovery hours separately, at 1.5x if it happens outside working hours.

Churn. This is the one that dominates. Estimate the affected customers, the share that leaves within 90 days, and their lifetime value (monthly fee times gross margin times average months retained). Churn is an estimate, but it is the difference between a rounding error and a board-level incident.

A worked example

Take a small SaaS company: $1.2 million in annual recurring revenue, 300 customers at about $100 per month, six employees whose work stops when the product is down, and two engineers who respond. The product goes dark for two hours on a Tuesday. Assume 2% of customers churn within 90 days, six customers at a lifetime value of $2,400 each.

The revenue line was $274. The churn line was $14,400. That ordering is typical: for subscription businesses the silent walk-aways dwarf the lost invoices, which is why the number you quote in the postmortem should never be just the revenue line.

The industry averages are for budget decks. The number that decides whether an outage gets a postmortem, and whether redundancy gets funded, is the one you calculate from your own revenue, payroll, and churn math. Everything else is a guess.

The hour you never count

That same hour is also an SLA breach for most services you run. Monthly uptime math, on a 30-day month:

One hour in a 30-day month works out to 99.87% uptime, which misses every commitment from 99.9% up. So the hour is not only a cost. On AWS, Azure, GCP, or DigitalOcean it may also entitle you to a service credit if you file inside the claim window, and the thresholds and deadlines for each provider are in our SLA credit claim guide.

Make the number stick

Turn the calculation into one line in your incident response template: cost = (revenue per hour x hours down) + (people idle x loaded rate x hours) + (affected customers x churn rate x lifetime value) + (engineers x loaded rate x recovery hours). Fill it in at the end of every postmortem. After three incidents you will have a distribution instead of an average, and you will know which past outages were actually expensive rather than merely annoying.

The one thing to do this week: pick the service that generates the most revenue, run the three-part calculation above, and add the result as a single line to your incident template. The next time something goes down, the first question is answered before anyone starts arguing about it. The remaining problem is knowing when the clock started, which means watching your services rather than the provider's status page; that is the part of the job UptimeAudit does for you.