💥 Quantifying Incident Impact: Customers, Revenue, and SLO Burn

“Some users were affected” is the most useless sentence in incident response. It tells a future reader nothing about whether this incident deserves a quarter of engineering time or a shrug. Quantifying impact is what turns a postmortem from a story into a prioritization tool — six months later, the impact number is the argument for funding the fix. This guide is a practical method for measuring what an incident actually cost, across three dimensions: customers, revenue, and SLO burn.

Why quantified impact matters

Impact is the currency you spend to justify reliability work. When a postmortem action item competes against a feature in planning, the feature has a revenue story and the action item has “it’ll help reliability.” Quantified impact gives the action item its own number to fight with: “this class of incident cost us an estimated 4,100 failed checkouts and burned 40% of the quarter’s error budget in 22 minutes.” Now it’s a real trade-off, not a vibe. Vague impact loses every prioritization contest by default.

Dimension 1: Customer impact

Start with who was affected and how badly. Aim for a defensible estimate, not false precision.

• How many. Estimate affected users from traffic during the window. If checkout saw 18,000 requests during the incident and error rate peaked at 38%, roughly 6,800 requests failed — map that to distinct users if you can.
• How badly. Distinguish severity of experience. A slow page is not a failed payment is not lost data. “Degraded,” “failed,” and “data loss” are three very different customer harms.
• Who. Was it uniform, or concentrated? An incident that hit 2% of users but included your three largest enterprise accounts is a different problem than 2% spread evenly.
• Visible or silent. Did customers notice and complain, or did it pass unseen? Both matter — silent impact still erodes trust and may surface later as churn.

State it plainly: “An estimated 6,800 checkout attempts failed over 22 minutes, affecting roughly 5,200 distinct customers, concentrated in the EU region.”

Dimension 2: Revenue and business impact

Translate customer harm into business terms leadership understands. Be transparent about assumptions — a labeled estimate is far more useful than no number.

• Direct lost revenue. For transactional systems: failed transactions × average value × an estimated recovery rate (some customers retry later; some don’t). “6,800 failed checkouts × ~$45 average order × ~40% not recovered ≈ $122k at risk” is honest if you show the math.
• SLA credits. If the incident breached contractual SLAs, credits owed are a hard, real cost worth naming.
• Operational cost. Engineer-hours spent responding, plus any emergency infrastructure spun up.
• Trust and downstream cost. Harder to quantify but worth a sentence: support ticket volume, social media visibility, at-risk renewals. Flag it qualitatively rather than inventing a number.

The goal isn’t accounting precision. It’s a good-faith order-of-magnitude that lets leadership weigh this incident against others and against the cost of preventing it.

Dimension 3: SLO and error-budget burn

If you run SLOs, this is often the cleanest impact signal because it’s already defined and measured. The error budget is the amount of unreliability you’ve agreed is acceptable over a window; an incident spends it.

• Compute the burn. If your availability SLO is 99.9% over 30 days, your budget is about 43 minutes of downtime that month. A 22-minute incident consumed roughly half of it in one event.
• Express it as a fraction. “This incident burned ~51% of April’s error budget” is instantly meaningful to anyone who runs SLOs — far more than raw minutes.
• Note the burn rate. Fast burn (a huge chunk of budget in minutes) signals a different class of risk than slow steady erosion, and may warrant a different response policy.
• Connect it to policy. If the incident blew the budget, that should trigger something — a reliability-focused sprint, a feature freeze, whatever your error-budget policy dictates. The postmortem is where you note that the trigger fired.

An impact section template

## Impact

**Duration:** 22 min (14:06–14:28 UTC), full recovery 14:40.

**Customer impact:** ~6,800 failed checkout attempts, ~5,200 distinct
customers, concentrated in EU. Experience: failed payment (not degraded).

**Revenue at risk:** ~$122k estimated (6,800 failures × ~$45 AOV × ~40%
not recovered). Assumptions labeled; not accounting-grade.

**SLA:** 2 enterprise accounts crossed monthly uptime threshold;
credits under review.

**SLO / error budget:** Burned ~51% of April's 99.9% availability
budget in a single event. Error-budget policy: triggers reliability
review this sprint.

**Operational:** ~9 engineer-hours across response and follow-up.

Common mistakes

• “Some users were affected.” The cardinal sin. Always reach for a number, even a rough one.
• False precision. “$122,431.17 lost” implies a certainty you don’t have. Round, and show your assumptions.
• Only counting one dimension. An incident with low revenue impact but a huge SLO burn is still serious; measure all three.
• Ignoring silent impact. Just because customers didn’t complain doesn’t mean there was no harm.
• No connection to policy. Measuring the error-budget burn and then doing nothing when it blows the budget wastes the whole exercise.

Wrapping up

Quantified impact is what makes a postmortem persuasive long after the incident is forgotten. Measure it across three dimensions — customers affected and how badly, revenue and business cost with labeled assumptions, and SLO/error-budget burn as a fraction — and connect the burn to your error-budget policy. Trade “some users were affected” for real numbers, and every downstream decision about whether to fund the fix gets easier and more honest.

Related

• Quantifying Customer and Business Impact in a Postmortem With AI
• Connecting Postmortems to SLO and Error-Budget Impact With AI
• Incident Metrics That Matter: MTTA, MTTR, MTBF