What Downtime Really Costs: A Breakdown by Company Size
"The average cost of downtime is $X per minute" shows up in every article on this topic, usually as a single number meant to apply to everyone. It doesn't. A one-person SaaS product and a 500-person company experience the same outage in completely different financial universes, with different fixed costs, different exposure, and different ability to absorb the hit.
Here's what the actual research says once you break it down by size, and why the curve between those sizes isn't a straight line.
The Numbers by Size
| Company size | Typical downtime cost | Source |
|---|---|---|
| Solo founder / 1-4 people | Direct revenue loss is often negligible; real cost is churn and founder time | See below |
| Small team, 5-25 employees | ~$100,000 per hour | ITIC (micro-SMB estimate) |
| Growing SMB, 25-100 employees | $8,000-$25,000 per hour, 57% report over $100,000/hour | Datto, ITIC |
| Mid-market, 100-1,000 employees | $200,000-$500,000 per hour | ITIC, industry benchmarks |
| Large enterprise, 1,000+ employees | $300,000-$1M+ per hour | ITIC |
A few of these numbers are worth sitting with. The ITIC estimate for organizations under 25 employees, roughly $100,000 an hour, sounds close to what mid-market companies pay. That's not a coincidence or an error, it reflects how much of downtime's cost has nothing to do with company size at all.
Regulated industries push these figures higher regardless of size. Financial services and healthcare organizations routinely report downtime costs well above the general benchmarks for their size bracket, since an outage there often triggers compliance obligations, breach notifications, or regulatory reporting on top of the ordinary business disruption. A 40-person fintech and a 40-person marketing agency are in the same row of this table by employee count, but rarely the same row by actual exposure.
Why the Curve Isn't Linear
Bigger companies have more absolute revenue at risk during an outage. They also tend to have more redundancy, more on-call staff, and more mature incident response, all of which shrink the actual damage per incident. A large enterprise with a 300,000-dollar-an-hour exposure also typically has automatic failover, a dedicated SRE team, and a tested runbook, all of which cut the realistic duration of an incident down from hours to minutes.
Smaller companies have less revenue at risk in absolute terms. But they typically have:
- No redundant infrastructure to fail over to, a single server or a single region often is the entire architecture
- No dedicated on-call rotation, often just one or two people who can actually fix anything, and only during their normal waking hours
- No incident response playbook, because there's never been a reason to write one until the first real incident forces it
- No pre-negotiated SLA credits or communication templates ready to go, meaning even the response itself is being improvised in real time
That combination is why a small business's downtime cost, relative to its actual revenue, often lands proportionally worse than a large enterprise's, even though the absolute dollar figure is smaller. A $100,000-an-hour estimate might be a rounding error for a company with billions in revenue. For a 15-person company doing a few million a year, it can be an existential event, not because the number itself is larger, but because there's nothing in reserve to absorb it.
A Worked Example at Each Size
Numbers land differently once you attach them to a specific, plausible incident rather than an abstract hourly rate.
- A 3-person SaaS product with $8,000 MRR goes down for 3 hours overnight. Direct revenue loss is around $30. The real cost shows up over the following month: a handful of trial users who churned because the app was broken when they tried it, and the founder losing half a day catching up on support tickets and reassuring existing customers.
- A 15-person startup with $2M ARR goes down for 2 hours during business hours. Direct revenue impact is modest, but 15 people sitting partially idle for 2 hours is 30 paid hours, and the outage coincides with a demo call for a prospective enterprise customer who now has doubts.
- A 60-person scale-up goes down for 90 minutes during a product launch. Beyond the direct cost, the launch's marketing push is now associated with an outage in the minds of everyone who tried the product for the first time that day, a much harder cost to reverse than the technical fix itself.
- A 400-person company with mature infrastructure has a regional failure that's caught and failed over in under 5 minutes thanks to redundancy and an on-call rotation, turning what could have been a costly incident into a footnote in an internal postmortem.
The pattern across all four: the technical severity of the failure matters less than how quickly it was caught and how much slack the organization had to absorb it.
What Doesn't Show Up in the Per-Hour Number
Every figure in the table above is a direct-cost estimate, and direct cost is only part of the picture. A few things it usually leaves out entirely:
- Idle payroll: once a company has actual staff, downtime doesn't just cost revenue, it costs wages paid for work that couldn't happen. A 15-person team idle for two hours is 30 paid hours with nothing to show for them, and that's before counting the time spent afterward catching up on what got delayed.
- Churn that outlasts the incident: the outage ends, but some percentage of affected customers don't come back. That's a cost that shows up on next month's numbers, not this hour's, which is exactly why it's so easy to underestimate in the moment.
- Reputation recovery time: research on brand impact after major incidents suggests it can take roughly 60 days for brand health metrics to recover, well after the technical problem is resolved and everyone internally has moved on.
- Support load: every outage generates a wave of tickets, DMs, and emails that someone has to triage and respond to, often for days afterward, on top of whatever the outage already cost in the moment.
- Sales cycle drag: for companies selling to other businesses, an outage during a trial period or a renewal conversation can quietly extend the sales cycle or kill a deal outright, a cost that never gets attributed back to the original incident.
None of these are captured in a clean per-minute figure, which is exactly why the headline numbers tend to undersell the real cost rather than overstate it.
Where Solo Founders and Small Teams Actually Fall
The size tiers above start at 5 employees, because most industry research is built around organizations with actual headcount to measure payroll and productivity loss against. A true solo founder or a 2-3 person indie SaaS team doesn't fit that model cleanly, and applying it directly tends to produce numbers that are technically accurate and practically meaningless.
For that audience specifically, the direct revenue math tends to be small enough that it's almost beside the point. What actually matters is churn, the founder's own consumed time, and reputation in a much smaller, more concentrated community, where a single bad experience can spread through a niche audience far faster than it would in a broad consumer market.
That's a different enough calculation that it deserves its own breakdown rather than a single row in this table, and it's worth treating as a distinct category rather than rounding it down to "small business" and using the same math as a 20-person company.
What Actually Moves the Needle at Any Size
Regardless of which row you fall into, the same lever matters most: how fast you find out. Every cost category above, direct revenue, idle payroll, churn, reputation, support load, sales drag, gets worse the longer an outage runs undetected, and better the moment someone actually knows there's a problem to fix.
That's true whether you're running a two-person SaaS product or a 200-person company, and it's the one part of the cost equation that's actually within your control regardless of your size. You can't buy your way out of every failure mode, but you can control the gap between something breaking and someone knowing about it, and that gap is where most of the avoidable cost in this entire table actually lives.
Pricing
Downdar offers three plans, each with a 30-day trial (credit card required):
Starter at $9 per month includes 10 monitors with 5-minute checks across HTTP, Ping, TCP, SSL, and DNS, plus 10 cron & heartbeat monitors, email alerts, and 1 status page.
Growth at $29 per month includes 50 monitors and 50 cron & heartbeat monitors, 1-minute checks, multiple global checkpoints, custom alert channels (Slack, Discord, Telegram, Teams, webhook), and 5 embeddable status pages.
Scale at $99 per month includes 250 monitors, 250 cron & heartbeat monitors, 25 status pages, and priority support with an uptime SLA.
The Bottom Line
There's no single number that describes what downtime costs. It costs something different at every size, and the honest version of that cost is always higher than the headline figure suggests, once you count the parts that don't fit neatly into a per-minute calculation. The one variable that helps at every size, from a solo founder to a 400-person company, is closing the gap between failure and detection.