What this prompt does
This prompt casts the model as an SRE lead and turns raw incident notes into a structured, blameless post-mortem. You feed it four inputs — [incident_summary], [timeline_data], [impact_description] and [environment] — and it returns a full report: executive summary, impact assessment, a UTC timeline table, a 5-Whys root cause analysis, what went well, what went wrong, an action-item table, and lessons learned.
The structure is what makes it useful. By forcing the 5 Whys, the prompt pushes past the first symptom toward a real root cause instead of stopping at "the database fell over." The [timeline_data] you paste becomes the backbone of the timeline table — detection, escalation, failed mitigations, and resolution all get rows — so the narrative stays factual. The [max_actions] cap is deliberate: it limits action items so they actually get finished rather than rotting in a backlog.
When to use it
- Right after a production incident, while the timeline is still fresh in everyone's memory.
- When you need a leadership-readable summary and an engineering deep-dive in the same document.
- To enforce blameless culture on a team that tends to point fingers.
- When postmortems on your team keep producing vague action items like "improve monitoring."
- To standardize the format across many incidents so they're comparable over time.
Example output
You get a Markdown report with a header block (date, severity, duration, status), a three-sentence executive summary for non-technical readers, a bulleted impact assessment, a Markdown timeline table in UTC, a numbered 5-Whys chain ending in the root cause, "what went well / wrong" lists, and an action-item table with columns for owner, priority, due date, status, and category. It closes with a lessons-learned section and a blameless-culture note.
Pro tips
- Put real timestamps in
[timeline_data]— the more granular, the better the timeline table. Include failed mitigation attempts, not just the fix that worked. - Quantify
[impact_description]: users affected, failed transactions, revenue. Numbers make the executive summary land with leadership. - Keep
[max_actions]low (5-8). I cap it because a post-mortem with twenty action items produces zero completed ones. - Describe
[environment]precisely (instance types, datastore versions, load balancer) so the root cause analysis reasons about the actual architecture. - After the first draft, ask the model to convert each action item into a tracked ticket title — specific, measurable, single-owner — before you paste it into your issue tracker.
- Treat the 5-Whys chain as a starting point and correct any link that doesn't match what your logs actually show; the model infers causes it can't verify.
