I build Tallwatch, so I have an obvious interest in you taking downtime seriously. So let me be honest up front about the number everyone quotes: the famous figures are mostly averages dressed up as facts, and the real answer to "what does an hour of downtime cost?" is "it depends, and you can actually work it out." This post is the framework I'd use to work out your number, plus the widely-cited industry figures for context — with sources, and with the caveat each one deserves.
The numbers everyone quotes (and what they really mean)
You've seen these in every vendor deck. Here they are with the honesty the decks leave out.
The most-quoted figure is Gartner's, which puts the average cost of IT downtime at around $5,600 per minute — roughly $336,000 per hour (Gartner, via Pingdom). It's a real, widely-cited number. It is also an average across large enterprises, and Gartner itself has noted the range is enormous — anywhere from about $140,000 to over $540,000 per hour depending on the business. Quoting the $336k as if it's your number is exactly the mistake to avoid.
The ITIC surveys back up the order of magnitude for bigger companies: across recent years, a single hour of downtime exceeds $300,000 for the large majority of mid-to-large enterprises, and for a meaningful share of them — particularly in finance, healthcare, and manufacturing — a single hour tops $1 million (ITIC, via TechChannel). Again: that's enterprises with thousands of employees and revenue to match.
For small businesses the figure is far lower — but it is not zero, and "lower" still hurts when you're small. A few hours offline can be a real dent in a month's revenue and a real hit to a reputation you've barely finished building. The lesson from all of these isn't a dollar figure to copy. It's that downtime is expensive enough, at every size, to be worth detecting fast. So let's compute your version instead of borrowing someone else's.
The five components of your real cost
Most people, when they estimate downtime cost, count lost revenue and stop. That's usually less than half the bill. Here are the five buckets that actually make it up.
1. Lost revenue
The one everyone starts with, and the easiest to estimate:
revenue per hour × outage duration × % of users affected
The "% of users affected" term is the one people forget. If your checkout is down but browsing still works, or one region is degraded while the rest are fine, you don't lose 100% of revenue — you lose the slice that hit the broken path. A partial outage is still real money, just not the whole pie. (For why a partial outage so often hides behind a green dashboard, see 200 OK still down.)
2. Lost productivity
Every engineer pulled into the incident, every support agent fielding angry tickets, every person who can't do their job because the internal tool is down — they're all being paid to not produce:
loaded hourly cost per person × number of people idled × duration
"Loaded" means salary plus the overhead that comes with employing someone, which is typically 1.25–1.4× base. Ten people pulled off their work for two hours is a real line on the bill, and it's invisible until you add it up.
3. SLA credits and penalties
If you've promised customers an uptime number, breaching it costs you directly — service credits, refunds, or in enterprise contracts, hard penalties. This one's a known quantity: read your own contracts and add up what an outage of a given length triggers.
4. Churn and reputation
The hardest to quantify, often the largest over time. Some fraction of affected users won't come back, and some fraction of those who stay will trust you a little less the next time. You can't measure this precisely in the moment, but you can estimate it: if even a small percentage of affected users churn, multiply that by their lifetime value and the number gets serious fast. A public, repeated pattern of outages compounds this — it shows up in renewals and in the deals you don't win because someone heard you were flaky.
5. Recovery and overtime
The cleanup after the lights come back on: overtime, the post-mortem, the emergency fixes, sometimes the goodwill credits you hand out to keep angry customers. Smaller than the others, but real, and routinely left off the estimate.
Add those five and you have your cost of an hour of downtime — a number grounded in your business, not a headline from someone else's.
The variable that dominates the whole bill: detection and response
Here's the insight that reframes everything above. Look at every component — revenue, productivity, churn, credits, recovery. Every single one is multiplied by duration. And duration is not fixed by the failure. It's mostly determined by how fast you find out and how fast you respond.
This is what MTTR — mean time to recovery — really measures, and it has two parts people conflate: time to detect and time to fix. You can't start fixing what you don't know is broken. An outage that your monitoring catches in one minute and routes to the right on-call engineer is a fraction of the cost of the same outage discovered forty minutes later when a customer finally tweets at you. Same root cause, same fix — a 40× difference in the duration that every cost bucket gets multiplied by.
So the highest-leverage thing you can do to lower your downtime bill isn't more redundancy or another nine on your SLA. It's shrinking the gap between "it broke" and "the right person knows." Fast, reliable detection is the cheapest insurance in this entire equation.
The hidden cost on the other side: false alerts
There's a second bill nobody puts in the deck, and it runs in the opposite direction: the cost of being told things are broken when they aren't.
Every false page has a real price. It's an engineer pulled out of focused work — or out of bed — to investigate nothing. Stack up enough of those and you get something worse than wasted hours: alert fatigue. When a third of your pages are false, people stop trusting the pager. They snooze it, they mute the channel, they assume the next one is noise too. And the one time it's a real outage, it sits unacknowledged while the duration — and every cost above — climbs. False alerts don't just waste time; they slowly disable the fast detection that was supposed to be lowering your bill in the first place.
So the goal is two-sided: catch real outages fast, and don't manufacture fake ones. You need detection that's both quick and trustworthy, because a noisy fast alarm degrades into a slow one the moment people stop believing it.
How this shapes what I built
This is the whole reason Tallwatch works the way it does. Checks run every minute from multiple regions so real outages surface fast, and an incident only opens when at least two regions agree the target is down in the same round — so the page you get is one worth answering, not a single probe's bad network hour. Fast detection lowers the duration that multiplies every cost bucket; consensus keeps false pages from eroding the trust that fast detection depends on. (And because the target you set shapes how hard you defend it, it's worth pairing this with what counts as a good uptime percentage.)
You don't have to take my framing on faith — you can run the math above against your own business, and you can do it on monitoring that costs nothing to start. The pricing is flat and the free plan runs in production, so the experiment of measuring your real exposure is free.
The honest summary: ignore the headline dollar figures, compute your own across all five buckets, and remember that almost every dollar in that total is multiplied by a duration you control with detection. The cheapest way to spend less on downtime is to find out about it sooner — and to trust the alarm when it rings.