Writing a SEV1 Incident Post-Mortem with AI: Prompt Templates for On-Call Engineers
How on-call engineers can use Claude for SEV1 rapid triage and blameless post-incident root-cause reports — prompt templates that speed up incident response without skipping rigor, with a full worked timeline.
During a SEV1, the bottleneck is rarely typing speed — it's structured thinking under pressure. AI is well-suited to incident response precisely because a good incident process is already a checklist: gather signal, form hypotheses, communicate status, and eventually write it all up. A structured prompt keeps that checklist moving even when the on-call engineer is exhausted.
Rapid triage: structure over speed
- Feed in the raw signal (alerts, dashboards, recent deploys) and ask for a ranked list of hypotheses, not a single guess.
- Ask explicitly "what changed recently" — deploys, config, feature flags, third-party status — before considering deeper code-level causes.
- Request a status-update draft for stakeholders in parallel with the technical triage, so communication doesn't stall while investigation continues.
Context: Checkout error rate jumped from 0.1% to 40% at 14:32 UTC. Alert: elevated 5xx on POST /api/checkout. Deploys in last 2 hours: payments-service v2.14.0 at 14:15 UTC. No infra changes logged. Third-party status pages (Stripe, our CDN) show no incidents.
Task: (1) List ranked hypotheses for the cause, given the deploy timing correlation. (2) Draft a one-paragraph stakeholder status update I can post now, before root cause is confirmed. (3) List the single fastest action to reduce customer impact right now (e.g. rollback) versus what to investigate in parallel.Given the tight correlation with the 14:15 deploy, the top hypothesis should be the new payments-service version — the model should recommend an immediate rollback as the fastest mitigation while investigation into the actual code change happens in parallel, not sequentially after.
The blameless post-mortem
Once the incident is resolved, prompt for a post-incident report using a fixed structure: timeline, impact, root cause (not just the proximate trigger), contributing factors, what went well, and concrete action items with owners. Explicitly instruct the model to avoid blaming individuals and to focus on systemic contributing factors — the same discipline good SRE culture already requires.
Context: Timeline — 14:15 payments-service v2.14.0 deployed; 14:32 error rate alert fired; 14:35 on-call paged; 14:41 rollback initiated after ruling out infra/third-party causes; 14:47 error rate back to baseline. Root cause: v2.14.0 introduced a new required field in the payment request schema that the mobile app (not yet updated) didn't send, causing validation failures. The staging environment tests a mocked mobile client that was already updated, so this wasn't caught pre-release.
Task: Write a blameless post-incident report.
Constraints: Do not name individuals. Focus contributing factors on process/systems (e.g. "staging test client was ahead of the real mobile release") not on who wrote the code. Include concrete action items with a clear owner role (not a person) and target type (e.g. "Payments team — add a contract test against the current production mobile client version").
Output format: Sections — Summary, Timeline, Impact, Root Cause, Contributing Factors, What Went Well, Action Items.| Section | What good output looks like |
|---|---|
| Root Cause | Names the actual mechanism (schema change + stale staging client), not just "a bad deploy" |
| Contributing Factors | Systemic — e.g. "no contract test between backend and the actual released mobile version" — not individual blame |
| Action Items | Specific, owned by a role, and would have actually prevented this incident if it existed beforehand |
Use AI to produce a clean first draft and to make sure the format is consistent across incidents. The actual root-cause determination should be reviewed by the engineers who lived through the incident before it's published.
SEV1 rapid triage and post-incident root-cause reporting are both named, reusable prompts in the Existing Project Analysis & Modernization program's Production Incident Management module.