How to Calculate the Cost of Downtime (Formula + Calculator)

Amazon loses an estimated $220,000 per minute during downtime. Cloudflare's 2019 outage cost their customers millions in aggregate lost revenue in under an hour. The Meta platform outage in October 2021 lasted roughly six hours and cost the company an estimated $60–100 million in lost revenue.

These numbers are memorable but not useful for most teams. The more relevant question is: what does downtime cost your business?

This guide walks through the full formula - including costs most teams forget to count - and shows worked examples for three common business types.

The Two Categories of Downtime Cost

Downtime costs fall into two categories:

Direct costs - revenue and productivity you lose immediately during the outage Indirect costs - long-term consequences that compound after the outage is over

Most downtime cost calculations only capture direct costs. The indirect costs are harder to measure but often larger.

Direct Downtime Cost Formula

For revenue-generating services

Hourly Revenue Impact = (Annual Revenue / 8,760 hours) × Affected Revenue %

Then:

Downtime Cost = Hourly Revenue Impact × Hours Down

Example - E-commerce site, $2M annual revenue, 100% affected:

$2,000,000 / 8,760 = $228 per hour
$228 × hours down = downtime cost

A 4-hour outage during a normal period: $912
A 4-hour outage during peak (Black Friday, 10x traffic): ~$9,120

For SaaS businesses (subscription revenue)

SaaS revenue is recurring, so a brief outage doesn't directly cancel subscriptions - but it affects:

1. Churn increase - customers who experience downtime are more likely to cancel at renewal
2. Support cost - engineering and support time during the incident
3. Refund/credit obligations - most SaaS contracts include SLA credits for excessive downtime

SaaS Downtime Cost = (Support hours × Hourly rate) + (Engineering hours × Hourly rate) + SLA credits issued

Plus the harder-to-quantify churn impact (covered in indirect costs below).

For B2B software with contracts

If your SLA promises 99.9% uptime and you breach it, you owe credits. Calculate:

Allowed downtime per month (99.9% SLA) = 43.8 minutes
Each minute over that threshold = credit owed per contract terms

For a $50K ARR customer with a 10% monthly credit per hour of excess downtime:

1 hour of excess downtime = $417/month credit × number of affected accounts

Engineering Cost During Downtime

This cost is almost always underestimated. During a production incident:

• The on-call engineer stops all other work
• Other engineers get pulled in for diagnosis
• DevOps, infrastructure, and sometimes leadership join incident calls
• Customer support is fielding tickets in parallel

Incident Engineering Cost = Number of engineers involved × Hours × Hourly fully-loaded cost

At a US startup with engineers averaging $75/hour fully-loaded:

3 engineers × 2 hours × $75 = $450 in engineering cost

That's for a short 2-hour incident with 3 people. A major 6-hour incident with 8 engineers:

8 × 6 × $75 = $3,600 in engineering cost alone

This doesn't include the opportunity cost of the features those engineers weren't building.

Complete Downtime Cost Calculator

Inputs you need:

Formula:

Revenue Lost = (MRR / 730 hours) × Affected % × Duration hours

Engineering Cost = Engineers × Duration hours × Hourly rate

SLA Credits = Affected accounts × Average contract value × Credit % per contract

Total Downtime Cost = Revenue Lost + Engineering Cost + SLA Credits

Worked example - Mid-size SaaS, $150K MRR:

Revenue Lost = ($150,000 / 730) × 100% × 3 hours = $616
Engineering Cost = 4 engineers × 3 hours × $85 = $1,020
SLA Credits = 50 affected accounts × $500/mo average × 5% credit = $1,250

Total = $616 + $1,020 + $1,250 = $2,886 per 3-hour incident

That's nearly $3,000 for a single 3-hour incident that doesn't make the news - for a $150K MRR SaaS product.

Indirect Costs (The Ones That Compound)

The formula above captures what you can measure immediately. The indirect costs often exceed the direct costs over time.

Churn from downtime

Research from various SaaS benchmarks suggests that customers who experience an outage have a 2–5x higher churn rate at their next renewal compared to customers who never experienced one.

If you have 500 customers paying $100/month:

• Your monthly churn might be 2% normally → 10 customers
• After a major outage, it might spike to 5% → 25 customers
• That's 15 extra churned customers × $100 × 12 months LTV = $18,000 lost

From a single bad outage.

Delayed sales from trust damage

Every prospect checking your status page during an outage is seeing your company at its worst. For B2B deals in evaluation, a visible outage can delay or kill a contract.

If you're closing 10 deals per month at $10K ACV and one deal stalls because the prospect saw a 4-hour outage during their trial:

1 delayed deal × $10,000 = $10,000 in delayed revenue

Cost of reputation recovery

After a major outage, you typically spend:

• Engineering time on a post-mortem and public writeup
• Marketing/comms time on customer communications
• Management time on enterprise customer calls
• Potential headcount to address the underlying infrastructure issue

These are real costs that rarely get attributed to the outage itself.

The "Cost of Monitoring" vs "Cost of Downtime" Math

Monitoring tools often feel like a cost. The comparison that puts it in context:

Scenario: A SaaS company with $80K MRR has no uptime monitoring. They have one major outage per quarter that goes undetected for 2 hours before a customer reports it, plus 2–3 smaller incidents per month.

Quarterly costs:

• 1 major incident × 2 hours detected late × $109/hr revenue = $218 extra revenue lost from detection delay
• 3 minor incidents × 30 min detected late = $55 extra revenue lost
• Engineering time investigating each: 3 incidents × 1.5 hrs × $85 = $383
• Total preventable quarterly cost: ~$650

Monitoring cost:

• Good monitoring with 1-minute checks and multi-region consensus: $9–$29/month = $27–$87/quarter

The ROI on monitoring is not subtle. $87 in monitoring cost prevents ~$650 in preventable incident costs - and that's ignoring churn impact.

Downtime Cost by Business Type

E-commerce

E-commerce has the most direct downtime-to-revenue relationship because every minute of downtime is a checkout that didn't happen.

Key formula:

Downtime cost per minute = (Monthly GMV / 43,200 minutes) × Checkout abandonment rate impact

E-commerce sites also experience halo effects: customers who couldn't check out during an outage often don't come back immediately. The real revenue impact is typically 1.5–2x the immediate lost transaction value.

Priority monitors for e-commerce:

• Checkout / cart API
• Payment processor integration (Stripe, Braintree)
• Product catalog / search
• Authentication

SaaS / B2B Software

Revenue impact is more indirect (subscription vs. transactional), but reliability directly affects renewal rates and expansion revenue.

What matters most: Response time during peak hours, not just availability. A B2B customer on a deadline who hits repeated slow load times is more likely to churn than one who experiences one clean 20-minute outage.

Priority monitors for SaaS:

• Auth API (/api/auth/session)
• Core feature API (your most-used endpoint)
• Webhook delivery (if applicable)
• Background job health (heartbeat monitors)

Developer Tools / APIs

Downtime for a developer API is felt immediately - developers build on top of your API and their applications fail when yours does.

What matters most: API availability and latency consistency. A 500ms p99 latency spike can break customer applications even when the API is technically "up."

Priority monitors for developer APIs:

• Primary API endpoint
• Authentication/token endpoint
• Webhook delivery
• Status page accuracy (developers check status pages immediately)

Reducing MTTR: The Highest-Leverage Investment

The downtime cost formula shows that MTTR (Mean Time to Recovery) is the multiplier. A 4-hour incident costs 4× as much as a 1-hour incident.

The two highest-leverage ways to reduce MTTR:

1. Reduce detection time (MTTD) Every minute between failure and detection is paid downtime. With 1-minute check intervals and multi-region consensus, average MTTD drops to under 1 minute. With 5-minute intervals, you're potentially 5 minutes behind every single incident.

2. Reduce investigation time Clear incident data - which regions failed, exact timestamps, per-region response codes - cuts diagnosis time from 30 minutes to 5. A monitoring tool that shows you "Frankfurt saw a failure but Virginia and Singapore didn't" tells you it's a routing issue before you even start investigating.

The math: If your current average MTTR is 45 minutes and proper monitoring reduces it to 15 minutes:

Time saved: 30 minutes per incident
Annual incidents: 24 (2/month)
Time saved annually: 12 hours
Revenue recovered: 12 hours × ($MRR / 730) = significant

For a $150K MRR business: 12 hours × $205/hr = $2,460 in recovered revenue annually - just from faster detection.

Summary

The numbers usually surprise teams doing this calculation for the first time. A business with $100K+ MRR is typically losing $500–$3,000 per significant incident when all costs are counted - and if they're running 5-minute check intervals with no consensus alerting, detection delay alone is costing them real money every quarter.

Monitoring with 1-minute check intervals, multi-region consensus, and proper alerting costs $9–$29/month. The math is straightforward.