Calculate the True Cost of Website Downtime

Assess the financial impact of outages with precision. Calculate revenue loss, refund costs, and productivity impact to make informed decisions about your infrastructure investments.

Downtime Cost Calculator

Percentage of affected customers who request refunds
Expected decrease in conversions during/after outage

Impact Analysis

$25,750 Total Loss
Cumulative Loss Over Time

Cost Breakdown

Revenue Loss: $25,000
Refund Costs: $1,250
Productivity Loss: $5,000
Conversion Drop Impact: $3,000

Annualized Impact

$309,000 Annual Loss

How It Works

1

Input Your Metrics

Enter your hourly revenue rate, outage duration, and any additional costs like refunds or employee impact.

2

Calculate Direct Losses

We calculate revenue loss, refund costs, and productivity impact based on your specific parameters.

3

Analyze Cumulative Impact

View the cumulative loss over time with our visual sparkline chart and breakdown analysis.

4

Export and Share

Copy summaries, download CSV reports, or share links with stakeholders for informed decision-making.

What does “downtime cost” mean?

Downtime means your website or service is not working for users. The cost is the money you lose while it is down — and sometimes after it is back.

This calculator adds common cost parts:

  • Lost revenue — sales or billable use you did not get.
  • Refunds — money you return to customers.
  • Lost productivity — staff who cannot work normally.
  • Conversion drop — fewer users complete a purchase or signup.

Simple formula

Duration (hours) = hours + (minutes ÷ 60)

Revenue loss = revenue per hour × duration

Total estimate = revenue loss + refunds + productivity loss + other selected costs

Worked example

Your site earns about $8,000 per hour.

It is down for 45 minutes (0.75 hours).

Revenue loss ≈ 8,000 × 0.75 = $6,000.

If 10% of that leads to refunds, add $600.

If 20 support staff cannot work well at $40/hour, add 20 × 40 × 0.75 = $600.

Rough total: about $7,200 for this one outage.

Use your real numbers. Industry averages are only a starting point.

When this estimate is weak

  • You do not know revenue per hour for this product.
  • The outage was partial (slow pages, not full down).
  • Brand damage lasts weeks and is hard to measure in one form.

Next steps

Compare allowed SLA downtime in the uptime reference. Or estimate vendor credits with the SLA Penalty Calculator.

How to choose revenue per hour

If you sell online, take last month’s revenue and divide by the number of hours your store was open. If you are B2B SaaS, use average revenue that depends on the product being online (new signups, usage billing, support capacity).

If you are not sure, use a low, medium, and high value. Run the calculator three times. Show the range to your manager. A range is more honest than one fake exact number.

Partial outages

Sometimes only one region or one feature fails. Then full “site down” math is too high. Reduce revenue per hour to the share of traffic that was hurt. Example: if 30% of users were affected, use 30% of normal revenue per hour.

Also write what “affected” means. Were pages slow, or fully broken? Could users still browse but not pay? A browse-only failure may lose conversions even when the home page still loads. In that case, model the conversion drop instead of pretending revenue was zero.

After you have a number

  1. Compare it to the yearly cost of better hosting, failover, or monitoring.
  2. Check if a vendor SLA credit also applies (separate calculator).
  3. Write down assumptions so the next incident uses the same method.

Ecommerce vs SaaS examples

Not every business loses money the same way. Two common patterns help you pick inputs.

Ecommerce (online store)

Money usually stops when checkout stops. If the store makes $120,000 in a 30-day month and runs 24 hours a day, revenue per hour ≈ 120,000 ÷ (30 × 24) ≈ $167 per hour on average. Peak hours (evenings, campaigns) can be much higher. For a flash sale, use the sale-hour rate, not the quiet Tuesday rate.

Ecommerce worked sketch

Peak revenue ≈ $4,000/hour. Outage = 30 minutes (0.5 hours).

Revenue loss ≈ 4,000 × 0.5 = $2,000.

Refunds on failed orders: add $300.

Support overtime (4 people × $35/hour × 0.5): add $70.

Rough incident total ≈ $2,370 before brand effects.

SaaS (subscription software)

Monthly subscription fees often continue even during a short outage. So “lost revenue” is not always the full MRR (monthly recurring revenue) divided by hours. Better inputs are:

  • New signups or upgrades you missed during the outage.
  • Usage-based billing you could not collect.
  • Credits or refunds you promise in your own customer SLA.
  • Churn risk if the outage was long or public.

SaaS worked sketch

You normally close $2,500/hour in new annual contracts during business hours (pipeline that needs the product demo and signup flow).

Outage = 2 hours on a weekday.

Missed pipeline ≈ 2,500 × 2 = $5,000 (not the same as cash today, but useful for planning).

You also issue $1,200 in goodwill credits to angry customers.

Eight engineers lose focus at ~$75/hour fully loaded × 2 hours = $1,200.

Rough total for this model ≈ $7,400.

SaaS leaders should label “pipeline” and “cash” separately so finance does not treat them as the same thing.

How to estimate revenue per hour

Use the simplest method that matches your business. Short sentences help teams agree.

  1. Store or marketplace: last 30 days of revenue ÷ hours the store was open.
  2. Peak-aware store: take revenue from similar peak hours only, then average those hours.
  3. Lead-gen site: (leads per hour × close rate × average deal value).
  4. SaaS signup funnel: (signups per hour × activation rate × average first-year value).
  5. Usage billing: average billable usage value per hour when the API is healthy.

If you only know monthly revenue and you run 24×7:

Revenue per hour ≈ monthly revenue ÷ (days in month × 24)

Example: €90,000 ÷ (30 × 24) ≈ €125 per hour.

If the outage hit only part of the product, multiply by the affected share of traffic or revenue. Example: 40% of users on the broken checkout → use 40% of the normal hourly rate.

Reputational cost caveat

Reputation means trust. Trust is real. It is also hard to put in one form field.

A short outage may cost only the hours you can measure. A public outage during a big launch may cost weeks of sales conversations, press questions, and renewals. That longer tail is reputational cost.

This calculator can hold a manual “other cost” number if you want. Treat it as a judgment call, not a precise science. Good practice:

  • Keep a base case with only measured costs (revenue, refunds, overtime).
  • Keep a stress case that adds a reputation add-on (for example 1× or 2× the base).
  • Write why you chose that add-on in one sentence.

Do not let a huge reputation guess hide weak inputs. Fix revenue-per-hour first. Then discuss brand risk with marketing or customer success.

Annualizing incidents

Annualizing means turning one incident into a yearly picture. It helps budgeting.

Simple method:

Yearly impact ≈ cost of one typical incident × expected similar incidents per year

Example: one incident ≈ $7,200. You expect about 4 similar events per year.

Annualized ≈ 7,200 × 4 = $28,800 per year.

Use history when you have it. If last year had two major outages and six small ones, model them as two different incident types. Do not multiply a rare “worst day” by 12 unless you truly expect that every month.

Compare the annualized number to the yearly price of fixes: better monitoring, multi-zone hosting, status page process, or on-call training. If fixes cost $10,000/year and annualized loss is $28,800, the investment case is easier to explain.

Sample low / mid / high scenario table

When inputs are uncertain, show a range. Managers trust a range more than one fake exact dollar.

Same 45-minute outage, three honesty levels

Scenario Revenue/hour Extra costs Rough total
Low $3,000 $400 ~$2,650
Mid $8,000 $1,200 ~$7,200
High $15,000 $3,000 ~$14,250

Totals ≈ (revenue/hour × 0.75) + extra costs. Extra costs = refunds + productivity + small reputation add-on. Replace with your numbers before you present.

Run the calculator three times. Save or screenshot each run. Label them Low / Mid / High. That habit prevents endless debate about one “perfect” input.

Related guides and calculators

Real-world walkthroughs: Downtime cost calculator — real-world examples.

Why the estimate matters for planning: Why a downtime cost calculator matters.

Allowed minutes by uptime target: SLA uptime → downtime reference.

Vendor credit estimate: SLA Penalty Calculator.

Recovery targets after disasters: RTO/RPO Impact Calculator.

Keep language simple when you share results: what happened, how long, which revenue rate you used, and what you excluded. Clear assumptions beat fancy charts.

Free
No signup needed
Local
Runs in your browser
USD/EUR
Currency options
PNG/CSV
Easy to share

Frequently Asked Questions

What factors affect downtime cost?
Key factors include hourly revenue rate, outage duration, refund percentage, conversion drop rate, and employee productivity costs. Each factor can significantly impact the total financial loss.
How do I calculate annualized downtime impact?
Multiply the single incident cost by the expected number of similar outages per year to get annualized impact. This helps budget for infrastructure improvements.
Should I include employee costs in downtime calculations?
Yes, include employee costs when staff cannot work effectively during outages, including support team overtime and lost productivity from system unavailability.
What's the difference between revenue loss and refund costs?
Revenue loss is the direct income you miss during the outage. Refund costs are additional expenses when customers demand their money back due to the service disruption.
How accurate are these downtime cost estimates?
Our calculations provide reliable estimates based on standard business metrics. Accuracy depends on the quality of your input data, particularly revenue rates and employee costs.
How should ecommerce and SaaS teams pick different inputs?
Ecommerce teams should start with checkout revenue per hour for the same time of day as the outage, then add refunds and support overtime. SaaS teams should separate cash that stops immediately from pipeline or signup value that is delayed. Add customer credits if you offer them. If only part of the product failed, scale revenue per hour by the share of users affected. When unsure, run low, mid, and high cases instead of one false exact number.
Should I include reputational damage in the total?
Only as a clearly labeled add-on. Reputation (lost trust, slower renewals, bad press) can be larger than the outage hours themselves, but it is hard to measure precisely. Keep a base case with revenue, refunds, and productivity only. Then add a separate stress case with a reputation amount and one sentence explaining why. Do not bury a huge guess inside “revenue per hour,” or your team will argue about the wrong input.
What does annualizing a downtime incident mean?
Annualizing means multiplying one typical incident cost by how many similar incidents you expect in a year. Example: $7,200 × 4 events ≈ $28,800 per year. Use that yearly figure to compare against the yearly cost of better hosting, monitoring, or failover. Do not annualize a once-in-a-decade worst case as if it happens monthly. Split rare major outages and common small ones into different models when you can.