How to Calculate the Cost of Website Downtime

The cost of website downtime is the total financial impact of a period when your site or service is unavailable or badly degraded. It is worth estimating because it tells you how much to invest in reliability: redundancy, faster monitoring, on-call coverage and better tooling. Published industry averages vary enormously by business, so this guide shows how to calculate your own figure rather than citing someone else's.

The components of downtime cost

The formula

downtime cost =
    (hourly revenue x peak factor x unrecovered share x hours down)
  + (people affected x loaded hourly cost x hours spent)
  + SLA credits and refunds
  + recovery costs
  + extra support cost

What each input means:

• Hourly revenue: annual revenue that flows through the site divided by 8,760 (hours in a 365-day year). For a business with strong weekday or daytime patterns, use revenue for the actual hours affected instead.
• Peak factor: how much busier the outage hours were than average. An outage during a sale or at lunchtime may have a factor of 2 or more; one at 4 a.m. may be 0.2.
• Unrecovered share: the fraction of lost sales that never come back. Some customers simply return later; others buy elsewhere. Subscription businesses often recover most revenue; impulse purchases and time-sensitive bookings recover little.
• Loaded hourly cost: salary plus benefits and overhead, divided by working hours.

Worked example (hypothetical numbers)

The following figures are invented for illustration. Consider an online store with:

• Annual online revenue of $1,752,000, which is $200 per average hour ($1,752,000 / 8,760).
• A 3-hour outage on a weekday afternoon, when traffic is typically twice the average (peak factor 2).
• An estimated 60% of lost orders not recovered later.
• Four engineers spending the 3 hours on the incident at a loaded cost of $80 per hour each.
• 120 extra support tickets at an estimated $5 each to handle.
• No SLA credits (retail customers have no SLA) and $300 of extra infrastructure and contractor cost.

Lost revenue:   $200 x 2 x 0.60 x 3 h      = $720
Productivity:   4 x $80 x 3 h               = $960
Support:        120 x $5                    = $600
SLA credits:                                = $0
Recovery:                                   = $300
-------------------------------------------------
Total estimated direct cost                 = $2,580

That is about $860 per hour of downtime for this store, roughly four times its average hourly revenue, before any intangible effects. Notice that staff time and support cost more than the lost sales. That is common for businesses where customers come back later, and it is why fast detection matters: each extra hour adds to every line.

SaaS example: when SLA credits dominate

For B2B software, lost revenue during an outage is often small because customers pay monthly regardless. The larger costs are SLA credits and churn risk. Suppose (again hypothetically) a SaaS company has 40 enterprise customers paying $2,000 per month, with an SLA that grants a 10% credit when monthly uptime falls below 99.9%. One outage of 50 minutes in a 30-day month pushes uptime to about 99.88% and triggers the credit for every customer:

Credits: 40 x $2,000 x 10% = $8,000

Had the incident been detected and fixed within the 43 minutes 12 seconds that 99.9% allows, no credit would have been owed. See SLA, SLO and SLI explained and the nines table.

Intangible costs

Some effects are real but hard to price:

• Churn. Repeated incidents give customers a reason to evaluate alternatives.
• Reputation. Public complaints on social media and review sites persist after the incident.
• Marketing waste. Paid ads keep sending visitors to a site that does not load.
• Search visibility. Search engines may slow crawling of a site that repeatedly returns errors; prolonged outages can affect how pages are indexed.
• Team morale. Frequent night-time incidents lead to burnout.

Rather than inventing a number, list these next to your direct-cost estimate when presenting it.

Reducing the cost of downtime

Downtime cost is roughly proportional to duration, so cutting detection and response time has a direct payoff. Total incident duration breaks down into time to detect, time to respond, time to diagnose and time to fix. Monitoring improves the first two directly:

• Shorter check intervals mean outages are detected sooner. Moving from 5-minute to 1-minute checks can cut several minutes off every incident.
• Alerts that reach the right person, via SMS, push or an on-call rotation, reduce response time outside working hours.
• A status page reduces support load during incidents.
• Maintenance windows and planned changes move risky work to low-traffic hours, reducing the peak factor.
• Postmortems reduce the chance of the same incident happening again.

Comparing cost of downtime with cost of monitoring

Once you have an hourly figure, compare it with what better tooling costs. In the store example, a few minutes saved per incident is worth more than a monthly monitoring subscription. As a reference, Uptime Tracker plans are Free ($0), Starter ($9 per month, 60-second checks, SMS alerts) and Team ($49 per month, 30-second checks, on-call and escalation); see pricing. To translate any uptime target into allowed minutes, use the uptime calculator.