Postmortem What-Went-Well Section Writer Prompt
Write a genuine 'what went well / strengths' section that captures the defenses and good calls that contained the incident — so the postmortem reinforces what to keep, not only what to fix.
- Target user
- Incident commander / SRE drafting the strengths section of a postmortem
- Difficulty
- Beginner
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a staff SRE who knows that a postmortem listing only failures teaches the team to stop doing the things that actually limited the damage. You write strengths sections that are specific and honest, never a participation trophy.
I will paste:
[INCIDENT TIMELINE: detection → mitigation → resolution, with timestamps]
[WHAT CONTAINED IT: any guardrails, alerts, rollbacks, runbooks, or human calls that helped]
[WHAT SLOWED THE BLAST RADIUS: rate limits, circuit breakers, redundancy, feature flags]
Do the following:
1. Identify what actually worked — separate luck ("we got lucky the traffic was low") from design ("the canary caught it"). Label each.
2. For each genuine strength, name the specific mechanism (the alert, the breaker, the decision) and what would have been worse without it. Be concrete; "good teamwork" is not a strength unless you can point to the moment.
3. Surface near-saves: defenses that almost failed and held by a thin margin — these are strengths AND risks worth flagging.
4. Reframe strengths so they are reinforceable: phrase each as something the team can deliberately keep or invest in, not a one-off.
5. Avoid backhanded praise that smuggles blame ("the team responded well despite the missing runbook" — split that into a clean strength and a separate gap).
Output format: a bulleted strengths list (Strength / Mechanism / What it prevented / Design-or-luck), then a 2-3 sentence summary paragraph for the document.
Guardrails: keep it blameless and balanced — do not inflate weak items into wins, and mark anything you cannot tie to a specific moment in the timeline as [UNVERIFIED]. I own the final wording and will confirm each claimed strength with the responders.
Why this prompt works
Postmortems that are pure failure lists quietly punish the team for the parts that went right. If the only feedback after every incident is a roster of mistakes, people learn that the response was a disaster — even when a circuit breaker, a fast rollback, or a sharp call by the on-call engineer prevented a far worse outcome. Naming those defenses explicitly tells the organization what to keep funding and what behavior to reinforce.
The discipline this prompt enforces is the separation of luck from design. “The blast radius stayed small because traffic happened to be low” is luck and should be labeled as a risk, not a strength; “the blast radius stayed small because the rate limiter shed load as designed” is a defense worth protecting. Conflating the two produces dangerous overconfidence — the team believes it has a control it does not have.
It also guards against two failure modes of strengths sections: empty praise and backhanded praise. “Good teamwork” with no anchor is noise, and “responded well despite the missing runbook” smuggles a gap into a compliment. By demanding a specific mechanism and a clean split between wins and gaps, the prompt keeps the section honest while leaving the final editorial judgment, and the verification with responders, to the human.