Postmortem Template (Learn, Don't Blame)
This prompt creates blameless postmortem documents that focus on systemic issues rather than individual mistakes. It structures incident analysis around timeline, root cause, impact, and preventive measures. The goal is organizational learning, not finger-pointing.
GPT / Claude / Gemini5 variables
Prompt
Create a postmortem for {INCIDENT}.
Input:
- What happened: {SUMMARY}
- When: {DATE_TIME}
- Duration: {DURATION}
- Impact: {IMPACT}
Rules:
- Use blameless language (focus on systems, not people)
- Include timeline with timestamps
- Identify root cause and contributing factors
- Create actionable prevention steps with owners
Output format:
SUMMARY (severity, impact, duration)
TIMELINE (key events with timestamps)
ROOT CAUSE ANALYSIS
- Primary cause
- Contributing factors
IMPACT
- Users affected
- Revenue/business impact
- Internal impact
WHAT WENT WELL (yes, really)
ACTION ITEMS (owner, deadline, priority)
- Prevention
- Detection
- Response
Incident: {INCIDENT}
Summary: {SUMMARY}
Date: {DATE_TIME}
Impact: {IMPACT}Quick brief
Purpose
Document incidents and outages to prevent repeat failures.
Expected output
A structured document containing: incident summary with severity and impact, detailed timeline of events, root cause analysis with contributing factors, action items with owners and deadlines, and what went well (not just what went wrong).
Customize before copying
Replace these placeholders with your own context before you run the prompt.
{INCIDENT}{SUMMARY}{DATE_TIME}{DURATION}{IMPACT}
Works well with
GPT
Claude
Gemini
Variations
Add 5 Whys analysis for root cause.
Include communication timeline (who was notified when).
Add lessons learned section with key takeaways.
Make it short-form (one-pager for minor incidents).
What this prompt helps you do
This prompt creates blameless postmortem documents that focus on systemic issues rather than individual mistakes. It structures incident analysis around timeline, root cause, impact, and preventive measures. The goal is organizational learning, not finger-pointing.
When to use it
Use after any significant incident, outage, missed deadline, or project failure where learning matters. Essential for engineering teams doing incident reviews, operations teams analyzing failures, or any situation where understanding what went wrong prevents future problems.
How it works
The prompt structures postmortems around facts and systems: what happened (timeline), why it happened (root cause analysis), what the impact was (quantified when possible), and what changes prevent recurrence. It explicitly avoids blame language and focuses on process improvements.
Best practices
Conduct postmortems within 48 hours while details are fresh. Include all involved team members. Focus on systemic causes, not individual actions. Assign owners to action items with deadlines. Share postmortems broadly for organizational learning.
Common mistakes
Blaming individuals instead of examining systems. Rushing to solutions without understanding root causes. Writing vague action items without owners. Not following up on action items. Making postmortems feel like punishment.
What you should expect back
A structured document containing: incident summary with severity and impact, detailed timeline of events, root cause analysis with contributing factors, action items with owners and deadlines, and what went well (not just what went wrong).
Limitations
Can't prevent incidents, only help learn from them. Requires honest participation from all involved. Action items need follow-through or nothing changes. Cultural resistance to blameless culture makes these less effective.
Model notes
Compatible with all major models. Claude tends to maintain blameless framing well. GPT creates clear action items. Gemini sometimes surfaces less obvious contributing factors. Works for any incident type.
Real-world applications
Engineering teams use this for production incidents. Operations teams use it for service outages. Project teams use it for delivery failures. Product teams use it for launch issues. Sales teams use it for deal losses.
How to tell if it worked
Effective postmortems mean action items get completed, similar incidents don't recur, team members feel safe sharing mistakes, and the organization builds institutional knowledge. If people hide information, your culture needs work.
Where to go next
Use Bug Hunter for technical root cause analysis. Pair with Meeting Agenda for postmortem sessions. Follow with Email to Executive for incident summaries.
Appears in collections
Code Review System (Helpful Feedback, Not Nitpicks)
Review code that improves quality, teaches developers, and ships faster.
Crisis Communication Plan (Transparent, Not Defensive)
Communicate during incidents, outages, or mistakes with honesty and speed.
Performance Optimization Workflow (Measure, Fix, Verify)
Make things faster through data, not guessing. Profile, optimize, benchmark.