Skip to content
DevOps AI ToolKit
Newsletter
All prompts
Post Mortems with AI Difficulty: Intermediate ClaudeChatGPTCursor

Postmortem Severity Classification Justifier Prompt

Turn an incident's impact facts and your org's SEV rubric into a defensible severity classification with written justification, plus flags for wherever the rubric is ambiguous.

Target user
SREs, incident responders, and incident review facilitators writing postmortems
Difficulty
Intermediate
Tools
Claude, ChatGPT, Cursor

The prompt

You are a senior SRE and incident review facilitator who classifies incident
severity using ONLY the impact evidence and the severity rubric provided. You
never inflate or deflate a SEV to fit a narrative, and you never assign blame.

I will paste:
[SEVERITY_RUBRIC] — our org's SEV0..SEVn definitions and thresholds.
[IMPACT_FACTS] — measured customer/business impact: users affected, duration,
data loss, revenue, SLA/SLO burn, regulatory exposure, blast radius.
[DECLARED_SEVERITY] — the SEV that was assigned live during the incident (if any).

Do the following:
1. Map each impact fact to the specific rubric criterion it satisfies. Quote the
   rubric line you are matching against.
2. Determine the highest severity supported by the evidence, and state it.
3. If [DECLARED_SEVERITY] differs from your classification, explain the gap
   factually — what was known at declaration time vs. what is known now.
4. Flag every place the rubric is AMBIGUOUS, missing a threshold, or forced you
   to interpret (e.g. partial outages, degraded-not-down, internal-only impact).
5. Recommend concrete rubric wording changes to remove each ambiguity.

Output format:
- Recommended severity (one line) + confidence
- Evidence-to-criterion table
- Declaration gap note (blameless, time-aware)
- Rubric ambiguity flags
- Suggested rubric edits

Guardrails: Stay blameless — classify the incident, never the responder who
declared it. Mark any figure you infer or assume as [ESTIMATE]. If evidence is
missing for a criterion, say "insufficient evidence" rather than guessing. A
human owns the final severity decision; you produce the justification, not the ruling.

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

Why this prompt works

Severity classification is where postmortems quietly go wrong. A SEV assigned in the heat of the incident is a snapshot of what one person believed at 3 a.m. with partial telemetry, but by the time the postmortem is written we have the full impact picture — and the temptation is either to retroactively “correct” the number in a way that embarrasses the declarer, or to leave the live number untouched even though it no longer matches reality. This prompt forces the model to treat classification as an evidence-mapping exercise against the written rubric, not as a vibe. By requiring that each impact fact be matched to a quoted rubric line, it makes the reasoning auditable: anyone reviewing the postmortem can see exactly which criterion pushed the incident to SEV1 rather than SEV2.

The design deliberately separates the declared severity from the evidence-supported severity and asks for a blameless, time-aware explanation of any gap. This matters because under-classification is almost always an information problem, not a judgment failure — the commander couldn’t see the full blast radius yet. Framing the gap as “known at declaration time vs. known now” keeps the analysis honest without turning it into a critique of the person who made a reasonable call under uncertainty. That framing is the single most important guardrail against the classic anti-pattern where severity reviews devolve into finger-pointing about who “should have called it a SEV1 sooner.”

The ambiguity-flagging step is where the prompt earns its keep over the long term. Most severity disputes are not really about a specific incident; they are about a rubric that never defined what “degraded” means, or that has thresholds for user counts but nothing for data integrity, or that can’t distinguish an internal-tooling outage from a customer-facing one. By making the model surface every place it had to interpret rather than read, and then proposing concrete wording fixes, each postmortem becomes an opportunity to tighten the rubric so the next incident classifies itself. This turns a one-off judgment into a compounding process improvement.

Finally, the guardrails reflect how consequential this number actually is. Severity often triggers legally binding notification clocks, SLA credits, and executive escalation, so the prompt explicitly refuses to let the model be the decision-maker — it produces a defensible justification and hands the ruling to a human. The requirement to mark inferred figures as [ESTIMATE] and to say “insufficient evidence” rather than guess protects against the worst failure mode: a confidently-worded classification built on numbers the model invented, which then gets copied into a customer-facing report as if it were measured fact.

Related prompts

More Post Mortems with AI prompts & error guides

Browse every Post Mortems with AI prompt and troubleshooting guide in one place.

Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.