We all know downtime costs money, but most teams don't actually calculate how much. The number is almost always higher than you think, and it's not just lost revenue—there are hidden costs that add up fast.
First: let's build a quick calculator to estimate your own cost. We've also built an interactive version here. Then we'll talk about what actually goes into it and how to reduce it.
A quick downtime cost calculator
Here's a simple way to estimate your downtime cost per hour:
| Line Item | Estimate |
|---|---|
| Average hourly revenue | $____ |
| Percentage of revenue lost per hour of downtime | ____% |
| Average engineering hourly rate (fully loaded) | $____ |
| Number of engineers pulled into an average outage | ____ |
| Average time per engineer spent per outage | ____ hours |
| Estimated lost deals/prospects per outage (at average deal size) | $____ |
Total estimated cost per hour of downtime:
(Hourly revenue × % lost) + (Engineering rate × Number of engineers × Hours per outage) + Lost deals
Let's do an example for a small SaaS business:
- $5,000/hour average revenue
- 30% lost per hour of downtime (realistic for a product people rely on)
- $150/hour fully loaded engineering rate
- 2 engineers pulled in per outage
- 1.5 hours per engineer per outage
- $3,000 lost deals per outage
Total per hour:
($5,000 × 0.3) + ($150 × 2 × 1.5) + $3,000 = $1,500 + $450 + $3,000 = $4,950/hour
That's almost $5,000 for a single hour of downtime—for a small business. For larger businesses it can be 10x or 100x that.
The hidden costs of downtime
The calculator above covers the big ones, but there are even more hidden costs that don't show up in a spreadsheet:
1. Lost trust
This is the biggest one that's hard to quantify. If a customer hits your outage at the wrong moment—say, right when they're trying to close a deal or run a critical report—they might not come back. Even if they do, their trust is eroded, and they're more likely to look at alternatives next time their contract is up.
2. Opportunity cost of engineering time
Every hour your engineers spend firefighting an outage is an hour they aren't shipping new features, fixing real bugs, or improving your product. That's work that doesn't get done, and it adds up over time.
3. Team burnout
If your team is getting paged all the time—even for things that aren't real outages—they burn out fast. Burnout leads to slower work, lower quality, and turnover, which is expensive to fix.
How to reduce downtime cost
There are two big levers here:
1. Reduce the mean time to recovery (MTTR)
The faster you fix an outage, the less it costs. To reduce MTTR:
- Make sure alerts reach the right person immediately (use escalation policies and on-call rotations)
- Have a runbook for common outages so you don't have to figure it out from scratch every time
- Make sure your status page updates automatically so customers know what's going on without opening tickets
2. Reduce false alerts
This is the one most teams miss. Every false alert trains your team to ignore alerts, which means when a real outage hits, they might not see it right away. It also burns out your team, which makes MTTR worse for real outages.
The best way to reduce false alerts is multi-region consensus: check from several regions at once, and only open an incident when at least two agree in the same round. That eliminates the entire class of false alerts where one region's network is having a rough time but your site is fine everywhere else.
Put it to the test
The best way to see how much downtime costs you is to track it. Keep a log of every outage: how long it lasted, how much revenue you lost, how many engineers were pulled in, how many deals you lost, and how many customers complained. After a few months, you'll have a real number—and it will probably be higher than you think.
Then fix the two big levers: reduce MTTR, and reduce false alerts. The second one is what we built Tallwatch for, and you can start free to test it without a credit card.