Website downtime cost: deconstructing the famous numbers

Direct answer: for most websites, one hour of downtime costs in the low thousands of dollars, not the $336,000 implied by Gartner's $5,600 per minute. The famous figures come from 2014 surveys of Fortune 1000 IT decision-makers and rarely fit smaller sites.

The famous downtime cost numbers, Gartner's $5,600 per minute, IDC's $1 million per hour, Amazon's $13 million per hour, are real citations. They are also answers to a question almost nobody asking you for a monitoring budget is actually asking. The honest cost of your downtime depends on your traffic, your revenue model, and what your customers can substitute for your service. For most sites the real number is far smaller than the headline figures, and the real risk is qualitative.

The headline numbers are not wrong. They are misapplied. This post traces where each one came from, explains why it rarely fits your site, and gives a calculation framework you can actually use.

Where the famous downtime numbers come from

Three numbers dominate the citation graph for downtime cost. Each has a real source, and each one has been quoted without context for over a decade.

$5,600 per minute (Gartner)

The most-cited figure traces to a 2014 Gartner blog post by Andrew Lerner titled "The Cost of Downtime", published July 16, 2014, that estimated the average cost of IT downtime at $5,600 per minute. Lerner himself noted in the same post that this was an average with a large degree of variance: one study he referenced put the actual range at $140,000 to $540,000 per hour, equivalent to roughly $2,300 to $9,000 per minute. The $5,600 figure is the midpoint of that range, not a universal constant. The original Gartner blog URL has since been retired, so the number is now widely cited through secondary copies; treat the precise figure as a directional benchmark rather than a confirmable primary source.

Two things to notice. The survey measured IT downtime across full enterprise stacks, including ERP outages, internal application failures, and back-office systems. Web-facing downtime is a subset, not the whole. And the surveyed organisations were medium-to-large enterprises, not the long tail of online businesses.

$1 million per hour (IDC, ITIC)

IDC and ITIC, two separate research firms often conflated in citations, publish annual surveys of enterprise IT reliability. The $1 million per hour figure most commonly traces to ITIC's Hourly Cost of Downtime survey. The 2024 edition reports that 41 percent of surveyed enterprises put hourly downtime cost in the $1 million to $5 million-plus range, with the top tier (financial services, energy, telecommunications) clustered at the high end.

The exact headline ITIC uses for the 2024 report is unambiguous about what is being measured:

41% of Enterprises Say Hourly Downtime Costs $1 Million to Over $5 Million

Same caveat as before. The respondents are typically Fortune 1000 IT operations, not online businesses in general. The number reflects the high end of a heavy-tail distribution, not a median, and the survey deliberately samples the segment with the largest cost exposure.

~$13 million per hour (Amazon)

The Amazon figure is derived arithmetic, not a survey. It takes Amazon's annual e-commerce revenue, divides by the number of seconds in a year, and produces a per-second revenue figure that is sometimes annualised back to a per-hour cost of downtime. Variants of this calculation circulated between 2019 and 2021. A 2021 Amazon outage was widely reported in the business press as costing tens of millions of dollars in lost sales over roughly one hour; precise dollar estimates varied across outlets and the underlying primary source is not independently verifiable, so treat the order of magnitude rather than any specific figure as the takeaway. Even at the lower end of those estimates, the per-minute cost runs two orders of magnitude above the Gartner average.

The Amazon number applies to Amazon. It applies to almost no other site.

Why these numbers rarely apply to your site

There are four common ways the famous figures get misused:

• Sample skew. The surveys behind these numbers measure enterprises with large IT estates and complex internal dependencies. A small SaaS, a marketing site, or a single-product DTC store has a smaller blast radius and a smaller cost surface.
• Scope mismatch. Survey 'downtime' usually means any IT system being unavailable, including internal tools, ERP, payroll, and back-end databases. Web outage is a subset. Quoting an IT downtime figure to budget for web monitoring inflates the case.
• Indirect-cost inclusion. The headline numbers often include lost employee productivity (engineers, support, sales unable to work) and contractual penalties. Those are real costs but they show up on different lines of the P&L than your hosting bill.
• Median versus mean. Heavy-tail distributions have a small number of large outliers (a payment processor going down) dominating the mean. Quoting the mean as if it applies to the median site is statistically misleading.

None of this means downtime is free. It means your number is different from the famous number, and it is your number that matters when you decide what to spend preventing outages.

What to actually calculate

Four categories add up to your real downtime cost. They are easy to estimate badly and harder to estimate well, but even a rough estimate is more useful than borrowing someone else's headline.

1. Direct revenue lost during the outage

For transactional sites, this is the clearest line. Take your average revenue per hour during the outage window and multiply by the duration. Cleaner if you split by hour of day; revenue at 4 AM and 4 PM are not the same.

Watch out for substitution. If your site goes down and customers come back ten minutes later to complete the order, the revenue is delayed, not lost. If they go to a competitor instead, it is gone. Cart abandonment data from your own analytics is the best proxy.

2. Internal team cost during the incident

Engineers stop shipping. Customer success answers tickets instead of doing their job. The on-call rotation absorbs hours that come out of feature work or sleep. Multiply the fully-loaded hourly cost of everyone involved by the duration of the response, including post-incident review and remediation.

This number is rarely tiny. A four-engineer incident lasting two hours, plus a one-hour post-mortem, at a fully-loaded $150 per hour, runs $1,800 per incident before anyone counts revenue.

3. Recovery cost

Refunds and chargebacks where applicable. Goodwill credits issued to keep customers from leaving. Support ticket surge during and after the outage. Re-engagement marketing if churn risk spikes. These costs land in the days following the outage, not during it, which is why they often get missed in the first estimate.

4. Trust and reputation damage

This category is real and is also the hardest to quantify honestly. You can proxy it by tracking churn rate before and after notable outages, by tracking NPS changes, by watching social media sentiment, or by measuring sales-cycle elongation for B2B customers asking pointed reliability questions. None of these proxies is perfect, but ignoring the category gives you a number that is too low.

Worked examples by business type

These are hypothetical scenarios meant to illustrate the framework, not specific customer figures. Plug in your own numbers when you do this for real.

Hypothetical: a DTC ecommerce store, $5 million ARR

Average revenue per hour: roughly $570 (revenue divided by 8,760 hours per year). Peak Thursday-evening or weekend hours might run 3 to 5 times that. A one-hour outage during a peak slot loses an estimated $1,700 to $2,800 in direct revenue, with maybe 40 percent recovered by returning customers, leaving net direct loss around $1,000 to $1,700. Add internal team cost ($1,800 for a typical incident response), recovery support ($400 to $800 in support tickets and goodwill credits), and the total lands at roughly $3,500 to $4,500 per peak-hour outage. Not the Gartner $5,600 per minute, but not nothing.

Hypothetical: a small B2B SaaS, $1 million ARR

Average revenue per hour: roughly $114. Revenue is not the right line for SaaS downtime. The real costs are SLA credit exposure (often 10 to 30 percent of monthly revenue for severe breaches, per typical SaaS SLA terms), churn risk (a small fraction of customers per outage, multiplied by lifetime value), and internal team response. A two-hour outage with an SLA breach might trigger $5,000 to $15,000 in service credits, plus the team cost, plus a hard-to-quantify churn increment. SaaS downtime cost is dominated by contractual and trust factors, not by per-minute revenue.

Hypothetical: a content site with ad revenue, $300K annual

Daily ad revenue is roughly $820. Each hour of downtime during organic-traffic hours costs around $35 to $100 in lost impressions, plus a small but real SEO impact if the outage coincides with crawler activity. A two-hour outage in this profile is closer to $100 to $200 in immediate revenue loss, plus the qualitative impact on returning-reader retention. The famous numbers grossly overstate this case.

Hypothetical: a paid API service, $2 million ARR

API revenue is more linear with uptime than any other model. Customers integrate your API into their products; your downtime cascades into their downtime, which means their angry customers become your angry customers. Direct revenue loss is straightforward (revenue per hour times outage duration), but the indirect cost is larger and shows up in renewal conversations months later. SLA penalty clauses in B2B API contracts are often more punitive than SaaS dashboard SLAs.

Hypothetical: a brochure marketing site

Direct revenue loss during an outage: $0. Internal team cost during incident response: real, but often nominal because the team rarely needs to wake up at night for a brochure site. Recovery cost: low. Trust damage: real but slow, and mostly relevant if a prospect happens to visit during the outage. The honest downtime cost for a brochure site is dominated by qualitative impressions, not currency. Spending a top-tier monitoring budget on a brochure site is hard to justify on cost arithmetic alone.

When the cost spikes

Downtime cost is not constant across the clock. A few factors that shift it materially:

• Peak versus off-peak hours. Most consumer sites see 3 to 10 times the traffic during peak hours compared to overnight. A one-hour outage at 8 PM and a one-hour outage at 4 AM are not comparable losses.
• Campaign windows. Paid advertising drives traffic to specific landing pages. An outage during a paid campaign window wastes ad spend in real time, on top of losing the conversions the campaign was meant to drive.
• Sales seasons. Black Friday, Cyber Monday, end-of-quarter B2B closing windows, holiday gift-giving periods. The same outage that costs $1,000 in March can cost ten times that in late November.
• Customer time zones. A US-only B2C site cares about evenings and weekends. A B2B SaaS serving global customers cares about Monday-morning hours rotating across timezones. Tailor monitoring intensity to when the cost actually concentrates.
• Outage clustering. The first outage of the month is expensive. The fourth outage of the month is exponentially more expensive in churn risk and trust damage, even if each individual outage is short. Cumulative impact compounds.

What the famous numbers do get right

The famous numbers exaggerate for most sites, but they are not wrong about everything. Three observations they capture correctly:

1. Downtime cost is non-linear. A two-minute outage is cheaper per minute than a two-hour outage. Customer abandonment, social-media amplification, and trust erosion accelerate as outage duration grows. The Gartner and ITIC surveys implicitly capture this by reporting on incidents large enough to be measurable; short blips do not show up in their data because they do not break things badly enough to count.
2. The indirect costs are real, even when they are uncomfortable to measure. Productivity loss from incident response, opportunity cost of delayed feature work, sales-cycle elongation. All of these show up somewhere on the P&L even when nobody books them as a downtime cost. The big surveys at least try to count them.
3. Recurring outages carry a multiplier on top of the per-incident cost. Customers tolerate one bad day. Three bad days in a quarter triggers renegotiation, churn, and lost deals that none of the single-incident calculations capture. The enterprise IT operations behind the famous numbers absolutely have data on this multiplier effect, even when their headline figure obscures it.

Hold both ideas at once. The famous figures are wrong for you in magnitude. They are right in shape.

The famous numbers are not lies; they are answers to a different question. The right calculation for you uses your traffic, your conversion math, your team's hourly cost during incidents, and your honest read on customer trust. Most sites land far below the headline numbers, and a few sites land far above them. Find which one you are before deciding what to fund.

Or, more usefully: invest enough in uptime monitoring and incident management to make the calculation irrelevant most months. Then the only number you really need is zero.