The four costs an incident actually generates
Most incident cost estimates are one multiplication: revenue per hour times duration. That number is real but it is rarely the largest one, and on internal-facing systems it can be zero while the incident is still expensive. Four distinct costs are generated by a single outage, and they behave differently.
Revenue that never returns. Not all interrupted revenue is lost revenue. A customer who cannot check out at 2pm and does at 3pm has cost you nothing but goodwill; a customer who buys elsewhere has cost you the sale. The share that comes back is measurable — compare the day after against a baseline — and separating it is what turns an alarming headline figure into a defensible one.
Responder time. Every person in the incident channel is being paid at a fully loaded rate to do something other than build. This scales with the number of people involved, and incident channels attract observers, so it grows faster than the incident does.
Displaced work. The postmortem, the remediation items, the customer communications and the re-planning all consume engineering hours after the incident is closed. On mature teams this is routinely the largest engineering component, because it involves more people for longer than the response did.
Service credits. Contractual, immediate, and usually small relative to the loss — which is a point worth making explicitly, and the SLA credit versus actual loss calculator exists to quantify the gap.
Totalling all four gives a number you can use for something. The single most useful derivative is cost per minute, because that is what every proposal to improve detection, alerting or rollback speed should be measured against.
How each term is built
Revenue loss is the product of four things: the hourly revenue rate, the duration, the share of users affected, and the share of the interruption that is not recovered later. The user share matters because partial failures are the common case — a failed region, a broken checkout path or one degraded tenant affects a slice, not everybody. Multiplying full hourly revenue by the full duration for a partial failure is the single most common way these estimates get inflated.
Duration is measured from the start of customer impact to its end. That includes the time before anyone noticed, which is exactly the part that improved monitoring removes, and excluding it makes detection improvements look worthless. If your incident record only captures time from page to resolution, add your average time to detect before entering it here.
Engineering cost is total hours multiplied by a fully loaded rate. Use loaded cost, not salary: an engineer costs their employer considerably more than their pay, and the fully loaded engineering hour calculator derives the correct figure from salary, benefits, overhead and the hours actually available. Count responder hours per person including handover, then add the displaced work separately, because the two are estimated from different evidence — one from the incident channel, one from the follow-up ticket.
Cost per minute is the total divided by duration in minutes. It answers the question every reliability proposal implicitly poses: if this change removes ten minutes from the average incident, what is that worth? Note that it is not constant across incidents — a short total outage has a much higher cost per minute than a long partial one, because the fixed response and follow-up cost is spread over fewer minutes.
Worked example: a 3.5-hour partial outage
Take the defaults: a 3.5-hour incident affecting 40% of users on a service carrying $20,000 an hour, with 30% of the interrupted revenue returning later. Five people respond for four hours each at a loaded rate of $205 an hour, 40 hours of work are displaced afterwards, and $2,500 of service credits are triggered. You have 14 incidents of this size a year.
- Revenue interrupted. $20,000 × 3.5 h × 40% = $28,000.
- Revenue never recovered. $28,000 × (1 − 30%) = $19,600.
- Responder hours. 5 × 4 = 20 hours.
- Total engineering hours. 20 + 40 displaced = 60 hours.
- Engineering cost. 60 × $205 = $12,300.
- Total. $19,600 + $12,300 + $2,500 = $34,400.
- Per minute. 3.5 h × 60 = 210 minutes, so $34,400 ÷ 210 = $163.81 a minute.
- Annualise. $34,400 × 14 = $481,600 a year.
Two things stand out. Engineering time and credits together come to $14,800, which is 43% of the total — a share large enough that halving the number of people pulled into each incident would be worth roughly $28,700 a year on its own. And at $163.81 a minute, a monitoring change that cuts fifteen minutes off average detection time is worth about $2,457 per incident, or $34,400 a year at this incident rate. Both of those are ordinary engineering decisions that now have a price attached.
What to do with the number
Compare the revenue half against the engineering half. The calculator tells you which is larger for your incident, and the answer directs the work. When lost revenue dominates, the highest-value change shortens the outage: faster detection, faster rollback, better failover. When engineering time and credits dominate, the highest-value change reduces the effort each incident consumes: tighter paging policy, fewer people summoned by default, runbooks that let one person resolve what currently takes five.
Use cost per minute as the yardstick for reliability proposals. Any change that shortens incidents has a value you can now compute: minutes saved × cost per minute × incidents per year. Compare that against the cost of the change. This is the same marginal test the cost of additional nines calculator applies to availability targets, at the level of a single improvement.
Take the annual figure to planning, not the per-incident one. A single $34,400 incident reads as unfortunate. The same incident fourteen times a year is $481,600, which is comparable to two engineers, and that framing is what gets reliability work prioritised against features. It is also the honest framing, because the incident rate is the thing you are actually choosing.
Be careful comparing across incidents. Cost per minute is not a constant of your system: it rises for short severe incidents and falls for long partial ones, because the fixed cost of responding is spread differently. Compare totals across incidents and use cost per minute only within a class of similar ones.
Revenue lost by duration and share of users affected
| Duration | 25% of users | 50% of users | 100% of users |
|---|---|---|---|
| 30 minutes | $2,500 | $5,000 | $10,000 |
| 1 hour | $5,000 | $10,000 | $20,000 |
| 2 hours | $10,000 | $20,000 | $40,000 |
| 4 hours | $20,000 | $40,000 | $80,000 |
| 8 hours | $40,000 | $80,000 | $160,000 |
Multiply by (1 − recovery share) to get revenue never recovered: at the worked example's 30% recovery, a 2-hour incident affecting 50% of users yields $20,000 × 0.70 = $14,000. Engineering time and credits are added on top and do not scale with duration.
Ways this estimate goes wrong
- Starting the clock at the page. Impact begins when customers are affected, not when your monitoring notices. Excluding time-to-detect makes every detection improvement look worthless, which is the opposite of the truth.
- Treating all interrupted revenue as lost. Deferred purchases are not lost sales. Measure the recovery share once from a real incident rather than assuming zero, or the total will be systematically overstated and lose credibility.
- Counting only the responders who typed. Everyone watching the incident channel is being paid to watch it. Observers are a real cost and one of the easier ones to reduce.
- Omitting displaced work. The postmortem, the remediation backlog and the customer follow-up often consume more hours than the response, and they land on people who were not even paged.
- Using salary instead of loaded cost. A salary-derived hourly rate understates engineering cost by whatever your benefits and overhead load is, and the error applies to every hour in the calculation.
- Applying peak revenue to an off-peak incident. A 3am outage on a consumer service costs a fraction of a midday one. Use the rate for the hours the incident actually spanned.
- Double-counting credits and revenue. A service credit reduces what a customer pays you next month; the lost revenue is what they did not buy during the outage. They are separate, but if your revenue-per-hour figure is derived from subscription billing you may already be counting the same money twice.
What this deliberately does not price
Churn, reputational damage, sales cycles that stall after a public outage, and the morale cost of a bad night on call are all real and none of them are estimated here, because any default figure would be invented. If a specific incident caused identifiable churn, add the lifetime value of the customers lost as a separate line and say so when you quote the total. Leaving them out makes this a conservative floor, which is the right posture for a number you intend to defend.
Where the incident cost feeds in
This figure is an input to three other decisions. It sets the value of an availability improvement, which the cost of additional nines calculator weighs against the cost of redundancy. It calibrates the error budget: if you run service level objectives, the error budget calculator tells you how many minutes you may spend, and this tells you what each one costs. And it prices the risk side of a recovery posture in the backup and DR cost calculator, where the same arithmetic applies to a rarer, larger event.
For a purely internal system where the cost is lost staff productivity rather than lost revenue, the IT downtime cost calculator builds that side of the number instead. And when the incident is your vendor's rather than yours, the SLA credit versus actual loss calculator shows how much of this total the contract will actually reimburse — a figure that surprises people the first time they compute it.
One habit is worth adopting: record the inputs to this calculation in the postmortem template itself. Duration, share affected, responder count, responder hours and displaced hours are all known within a week of the incident and forgotten within a month. A year of recorded incident costs is a far stronger argument for reliability investment than any single dramatic outage, and it costs nothing to collect if you capture it at the time.
Key terms
- Time to detect
- The interval between customer impact starting and the team becoming aware. Part of the incident duration, and usually the cheapest part to shorten.
- Mean time to recover (MTTR)
- Average incident duration across a period. Multiplied by cost per minute and incident count, it gives your annual incident cost.
- Displaced work
- Engineering hours consumed after the incident closes: postmortem, remediation, customer follow-up and re-planning.
- Recovery share
- The proportion of interrupted revenue that arrives later because customers return. Subtracting it distinguishes delayed revenue from destroyed revenue.