💸 Estimating Incident Cost and Financial Impact With AI

The first question my VP asked after a four-hour checkout outage was not “what broke.” It was “what did this cost us?” I did not have an answer, and the silence that followed taught me something: if you cannot put a number on incident impact, the work to prevent the next one never gets funded. The trouble is that building a credible cost estimate under pressure, with half a dozen variables and a finance team that will scrutinize every assumption, is genuinely hard. This is where AI earns its keep — not by guessing the number, but by structuring the math so a human can defend it.

Why finance and engineering speak different languages

Engineers think in error rates and p99 latency. Finance thinks in revenue per minute, contractual SLA credits, and labor cost. When you hand a CFO a Grafana screenshot, you get blank stares. When you hand engineering a spreadsheet of “estimated EBITDA impact,” you get eye-rolls. AI is a useful translator between these two worlds because it can take raw incident facts and reframe them in the vocabulary each audience trusts.

I now keep a structured prompt that takes incident duration, affected services, traffic baseline, and conversion rate, then drafts a first-pass impact model with the assumptions called out explicitly. The key word is drafts. The model never fetches our real revenue figures or commits a number to a board deck. It builds scaffolding I fill in and verify.

The four cost buckets worth modeling

Most incident cost estimates fall apart because they only count one thing. A complete estimate has at least four buckets, and I ask AI to break the impact down across all of them:

• Lost revenue — transactions that did not happen during the degradation window, adjusted for what recovers later versus what is gone forever.
• SLA and contractual credits — penalties owed to customers under signed agreements, which are often the largest and most overlooked bucket.
• Labor cost — responder hours, plus the opportunity cost of pulling six engineers off roadmap work for a day.
• Reputational and churn cost — the fuzziest bucket, where AI helps you reason about ranges rather than pretend precision.

Pro Tip: Ask the model to separate “recoverable” from “permanently lost” revenue. A user who retries a failed purchase ten minutes later is not lost revenue, and conflating the two inflates your number and destroys your credibility the moment finance catches it.

Feeding the model the right inputs

Garbage in, confident garbage out. Before I let AI near a cost estimate, I gather the hard facts: precise start and end timestamps from monitoring, the list of degraded endpoints, and a traffic baseline for the same hour on the prior comparable day. Tools like Claude are good at holding all of this context and reasoning about it consistently. I paste the raw numbers and ask for the model to show every step of its arithmetic so I can audit it line by line.

What I never do is let it assume the baseline. If I do not have real conversion data, I tell it to leave that variable as a labeled placeholder rather than hallucinate a plausible-looking 2.3 percent. A visible blank is honest. A fabricated number is a liability.

Modeling ranges, not false precision

The single biggest mistake in incident cost estimation is presenting one number. Real impact is a range, and AI is good at reasoning about ranges when you ask it to. I prompt for a low, expected, and high scenario, each with its driving assumption stated. The low case might assume most revenue recovers; the high case assumes full churn of affected enterprise accounts.

Presenting “between $180K and $420K depending on enterprise churn” is far more defensible than “$300K,” because it invites the conversation about which assumption matters most. That conversation is usually where the real prevention budget gets unlocked.

Where the human absolutely owns the output

Let me be blunt about the line here. AI drafts the model; humans own the number. The estimate that goes to leadership is signed by a person who checked every assumption against real data. No model should pull live financial figures, file an SLA credit, or send a cost statement to a customer. Those are actions with legal and financial consequences, and an automated system has no business taking them.

I treat the AI output the way I treat a junior analyst’s first draft: useful structure, plausible reasoning, and absolutely not something I forward without review. The synthesis and the framing are where AI shines. The decision about what the company actually believes the incident cost is a human one. The free AI Incident Response Assistant is built around exactly this division of labor — it helps you assemble and communicate, never act.

Building a reusable estimation prompt

After doing this a few times, I templated it. I keep a saved prompt in my prompt workspace that asks for the four buckets, demands stated assumptions, and outputs both an engineering-facing breakdown and a one-paragraph executive summary. Standardizing the prompt means every incident gets costed the same way, which makes quarter-over-quarter comparisons actually meaningful.

If you want a head start, the prompts library and our prompt packs include incident-analysis templates you can adapt. The goal is consistency: the same buckets, the same assumption discipline, every time.

Turning cost data into prevention

The point of all this is not the post-incident theater. It is funding. When I can show that flaky deploys cost us six figures last quarter, the case for better canary analysis writes itself. AI helps me roll up costs across multiple incidents to find patterns — three of last quarter’s five most expensive incidents shared a root cause in the same payment dependency. That is the kind of synthesis that changes roadmaps.

Conclusion

A good incident cost estimate is a forcing function for prevention, but only if it is credible. Use AI to structure the math, separate recoverable from lost revenue, model ranges instead of false precision, and translate between engineering and finance. Then put a human name on the final number. The model builds the spreadsheet; you sign it. That boundary is what keeps the estimate trustworthy and keeps the prevention budget flowing. For more on the analysis side of incidents, browse the incident-response category.