"What does an hour of downtime actually cost us" is a question most companies can't answer precisely. That's usually fine, until it's the exact question a founder or board member asks right after an incident. Here's a framework that gets close enough to be useful without needing a data science project.
The three cost layers most calculators miss
- Direct revenue loss. The obvious one: average hourly revenue attributable to the site, multiplied by downtime hours, adjusted for the share of revenue that actually depends on the site being up. A B2B lead-gen site's loss during a 2am outage looks very different from a global ecommerce site's.
- Recovery cost. Engineering and on-call time spent diagnosing and fixing the issue, plus any contractual SLA credits owed to affected customers. This is a real, often-overlooked line item, especially for B2B SaaS with uptime guarantees in contracts.
- Trust and future-revenue impact. Harder to quantify, but real. Repeat-purchase ecommerce and SaaS businesses see measurable churn and conversion dips following visible outages, particularly if the outage happens more than once in a short window.
A simple formula to start with
| Input | How to Estimate It |
|---|---|
| Average hourly revenue via site | Monthly revenue divided by (30 times average daily active hours) |
| % of revenue actually blocked by downtime | 100% for pure ecommerce checkout; lower for lead-gen or content sites where a form can be resubmitted later |
| Recovery cost per incident | Engineer hourly cost times hours to diagnose and fix |
| SLA credits owed (if applicable) | Per-contract terms, summed across affected customers |
Multiply the first two rows together for direct loss, then add recovery cost and SLA credits for a conservative total. This deliberately excludes the trust and future-revenue layer, since it's genuinely hard to estimate without historical data. Treat it as a real but unquantified additional cost, not zero.
Why traffic timing matters more than average downtime length
A 2-hour outage during a low-traffic overnight window can cost less than a 20-minute outage during a peak sales window: a product launch, a paid campaign's send time, a Black Friday afternoon. Uptime monitoring and incident response priority should weight this. Know your traffic curve, and treat outages during known peak windows as a different severity tier than the same outage overnight.
Where the real leverage is: reducing time-to-recovery
Since some downtime is statistically inevitable even with strong infrastructure, the highest-leverage investment for most companies isn't chasing an extra 0.05% of uptime. It's cutting the time between "something broke" and "it's fixed and verified." That means real uptime monitoring with alerts that reach a person (not a dashboard nobody watches), a written incident response runbook, and a status page so customers aren't guessing during an incident. A well-rehearsed 15-minute recovery beats an ad-hoc 3-hour scramble on the exact same underlying bug. Using the formula above, the cost difference between those two scenarios is usually the single biggest number in this whole exercise.
FAQ
How do you calculate the cost of website downtime?
Start with direct revenue loss: average hourly revenue multiplied by downtime hours, adjusted for the share of revenue that actually flows through the site. Then add recovery costs (engineering time, any SLA credits owed to customers) and a conservative estimate for customer trust and future-purchase impact, which is harder to quantify but real for repeat-purchase businesses.
- Direct revenue loss alone understates the true cost for most businesses.
- Recovery costs and trust impact are real line items, not soft or ignorable ones.
Is a fast recovery more important than preventing downtime entirely?
Both matter, but for most businesses a fast, well-rehearsed recovery process delivers more cost reduction per dollar spent than chasing marginal additional uptime past a reasonable baseline like 99.9%. Some downtime is statistically inevitable, and an untested recovery process turns a 10-minute incident into a multi-hour one.
- A rehearsed incident response plan often reduces cost more than incremental uptime investment.
- Untested recovery processes are why short outages become long ones.