Assess the financial impact of outages with precision. Calculate revenue loss, refund costs, and productivity impact to make informed decisions about your infrastructure investments.
Enter your hourly revenue rate, outage duration, and any additional costs like refunds or employee impact.
We calculate revenue loss, refund costs, and productivity impact based on your specific parameters.
View the cumulative loss over time with our visual sparkline chart and breakdown analysis.
Copy summaries, download CSV reports, or share links with stakeholders for informed decision-making.
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:
Duration (hours) = hours + (minutes ÷ 60)
Revenue loss = revenue per hour × duration
Total estimate = revenue loss + refunds + productivity loss + other selected costs
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.
Compare allowed SLA downtime in the uptime reference. Or estimate vendor credits with the SLA Penalty Calculator.
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.
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.
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:
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.
Use the simplest method that matches your business. Short sentences help teams agree.
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.
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:
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 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.
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.
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.