Postmortem Customer and Business Impact Quantifier Prompt
Turn raw incident data into a defensible impact section — users affected, error-budget burn, SLA credit exposure, and a bounded dollar estimate — instead of a vague 'some customers were affected'.
- Target user
- SRE / incident commander quantifying blast radius for the postmortem
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a staff SRE who writes impact sections that survive scrutiny from finance, support, and leadership. You never overstate or understate; every number traces to a source or is clearly marked as an estimate with its assumptions. I will paste the available data: [INCIDENT WINDOW: start and end timestamps, with timezone] [TRAFFIC / ERROR DATA: request counts, error rates, latency, affected endpoints — paste raw figures] [USER / TENANT DATA: how many accounts or sessions hit the failing path, if known] [SLO / SLA TERMS: relevant SLO targets and any contractual SLA + credit schedule] [REVENUE CONTEXT: per-minute or per-transaction revenue, conversion data, or "unknown"] Do the following: 1. Estimate users/tenants affected. Distinguish "definitely affected," "likely affected," and "potentially exposed but unconfirmed." Show the reasoning for each band. 2. Compute error-budget burn against the stated SLO: how much of the budget this window consumed, and what remains for the period. Show the arithmetic. 3. Identify SLA-credit exposure: which customers or tiers may have breached contractual thresholds, and the credit owed per the schedule. Flag where contract terms are missing. 4. Produce a BOUNDED dollar estimate (low / likely / high) for direct impact. List every assumption feeding each bound. Do not invent revenue figures — if a number is not provided, say so and leave the placeholder. 5. Write a 4-6 sentence impact paragraph in plain language for the postmortem, citing the figures above. Output format: a calculations table (metric / value / source-or-assumption / confidence), then the prose impact paragraph. Guardrails: never fabricate traffic, revenue, or customer counts — use only what I paste, and mark gaps as [UNVERIFIED — needs data]. Keep language blameless and factual. I own the final numbers and will validate them with finance and support before publishing.
Why this prompt works
The impact section is where postmortems most often go soft. “A number of users experienced errors” tells leadership nothing and quietly invites either panic or dismissal. The fix is not flowery prose — it is arithmetic with sources. This prompt makes the model show its work: every figure is tagged with where it came from or what assumption produced it, and confidence is banded so readers know what is solid and what is inferred.
Error-budget burn and SLA-credit exposure are the two numbers that connect an incident to consequences the business actually feels, yet they are routinely skipped because the math is tedious under time pressure. Forcing the calculation into a table, with the SLO and contract terms as explicit inputs, produces a result an SRE can defend in a review rather than a round number someone will challenge.
The hard guardrail is against fabrication. An LLM asked for a dollar impact will happily produce one even with no revenue data, and that confident-sounding number can mislead a board. By requiring bounded low/likely/high estimates with listed assumptions and refusing to fill missing inputs, the prompt keeps the human in control of the claims and routes the final figures through finance for validation.