What the Operational Incident Cost Calculator does
This calculator estimates what an outage or operational incident costs your business, as a low, expected and high range rather than a single number that looks more certain than it is. It adds up five things you can reason about: revenue that is lost for good, the time of the people who respond, the productivity of staff who cannot work normally, service credits owed under your SLA, and one-off recovery costs.
It is for pricing an outage - to size a reliability investment, write a post-incident review or explain an incident to finance. It is not a security incident log; for recording and handling a security incident, use the incident response workspace instead.
How to use it
- Enter the duration as three figures: a low, an expected and a high estimate in minutes. For a past incident all three can be the same; for planning, use a range.
- Enter normal revenue per hour, the share of it the incident affected, and the share of affected revenue that is lost for good rather than recovered when customers retry later.
- Enter the responders, their loaded hourly cost and their follow-up hours, and any staff who could not work normally and how much of their productivity was lost.
- If you have an SLA, enter the monthly fees it covers, the measurement period, earlier downtime this period and the contract's credit table (availability below X% gives a Y% credit).
- Add one-off recovery costs, then read the range, the breakdown and copy or download the report.
Reading the results
The expected figure is the one to quote; the low and high figures show how wide the uncertainty is. If the high figure is several times the expected one, the duration or the lost-revenue share is poorly known, and narrowing that estimate is worth more than refining anything else.
The component bars show what drives the cost. When SLA credits dominate, the contract's tier boundaries matter more than minutes; when revenue dominates, faster detection and partial degradation (keeping checkout working while search is down) pay back first.
Availability this period is calculated like the SLA uptime calculator: measured seconds minus downtime, over the period. Earlier downtime in the same period counts, which is how a short incident can push a customer into a bigger credit tier.
Worked example: a checkout outage in an online shop
An online shop normally takes 12,000 an hour. Its checkout fails for an expected 90 minutes (low 45, high 240), hitting 60% of revenue; about half of the affected customers never come back to complete their order (low 25%, high 80%).
Expected lost revenue is 12,000 x 1.5 h x 60% x 50% = 5,400. Four responders at a loaded 80 an hour spend 1.5 hours plus 2 hours of follow-up each: 4 x 3.5 x 80 = 1,120. Thirty customer-service staff at 40 an hour lose half their productivity for the 90 minutes: 30 x 1.5 x 50% x 40 = 900.
Business customers paying 20,000 a month have an SLA measured over a 30-day month. 90 minutes is 5,400 of 2,592,000 seconds, so availability is 99.79%, below the 99.9% threshold: a 10% credit, 2,000. With 1,500 of overtime and refunds, the expected cost is 10,920. The low scenario comes to 5,180 and the high one to 35,360.
Formulas and scoring rules
- Lost revenue
revenue per hour x hours down x affected% x unrecovered%- Response effort
responders x (hours down + follow-up hours) x loaded hourly cost- Lost productivity
affected staff x hours down x productivity lost% x loaded hourly cost- Availability for the SLA
A = 1 - (earlier downtime + duration) / period lengthPeriod lengths as on the SLA uptime calculator: 30-day month 2,592,000 s; average month 2,629,800 s.- SLA credit
credit = fees x largest credit% whose threshold A falls belowExactly at the threshold earns no credit.- Total
total = revenue + response + productivity + credits + recoveryComputed separately for low, expected and high; shown to the whole currency unit.
Why lost revenue is not revenue per hour times hours
Multiplying normal revenue by the length of the outage assumes every customer who could not buy is gone for ever. Usually many simply come back an hour later. The unrecovered percentage is the honest part of the estimate: compare orders in the days after the incident with the same days a week earlier, and the missing difference is your recovery rate.
The opposite mistake also happens. A subscription business may lose no revenue on the day and still lose customers at renewal because of the outage. That delayed churn is real but cannot be derived from minutes of downtime, so the calculator leaves it out and says so rather than guessing.
Limitations: what the result does not prove
- The result is an estimate built from your inputs, not a measurement. Its value is in making the assumptions explicit and easy to challenge.
- Reputational damage, churn at renewal, regulatory fines and costs of data loss are not estimated. Add any known amounts as recovery costs.
- Credit tiers are applied as a simple table. Contracts often add conditions - claims must be filed within a deadline, credits are capped, partial outages count differently - that change what is actually owed.
- Staff costs use the loaded hourly rates you enter; if people responded outside working hours, overtime or on-call payments belong in recovery costs.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
Frequently asked questions
How do I calculate the cost of downtime?
Add the revenue lost for good, the cost of the people who responded, the productivity lost by staff who could not work, any SLA credits owed and one-off recovery costs. Doing it as a low, expected and high range is more honest than a single figure, because the duration and the lost-revenue share are rarely known precisely.
How do SLA service credit tiers work?
The contract lists availability thresholds with a credit for each - for example 10% of the monthly fee below 99.9% and 25% below 99%. If the month's availability falls below a threshold, that credit applies; when several apply, the largest one is used rather than adding them together.
Should I use the whole revenue per hour or only the affected part?
Only the affected part. A search outage may leave checkout working, and a regional outage hits only that region's sales. Enter your normal revenue per hour and then the percentage the incident actually touched, so the two assumptions stay visible separately.
How is this different from the incident response workspace?
The incident response workspace is for handling a security incident: timeline, evidence and actions. This calculator prices an operational outage in money, for a post-incident review, a business case or a conversation with finance. They answer different questions and can be used together.
Why does a short outage sometimes cost much more in SLA credits than a long one?
Because credits depend on the whole period's availability, not the single incident. If earlier outages already used most of the month's allowance, a few extra minutes can cross a tier boundary and jump the credit from 10% to 25% of fees. Enter earlier downtime to see this.
What loaded hourly cost should I use for responders?
Use pay plus employer on-costs such as taxes, pension and benefits, converted to an hourly figure. Finance teams usually have a standard loaded rate by grade. On-call allowances and overtime premiums paid because of the incident can go in recovery costs instead.
Last reviewed by the A2Z.Tools team against the sources listed above.
