Incident Post-Mortem Template

Nobody Learns From Incidents. Post-Mortems Change That.

On November 24, 2023, Google Cloud experienced a 90-minute outage that took down Spotify, Discord, Snapchat, and dozens of other services. Within 48 hours, Google published a detailed post-mortem identifying the root cause, timeline, and corrective actions. That's not just good PR — it's the reason Google Cloud doesn't make the same mistake twice.

Most companies handle incidents very differently. The site goes down, everyone scrambles, someone deploys a fix, and the team moves on. No documentation. No analysis. Just collective relief and a prayer it doesn't happen again.

Why Teams Skip Post-Mortems (and Regret It)

A PagerDuty survey found that 77% of organizations experience repeat incidents — meaning the same class of failure happens more than once. The primary reason? No formal post-mortem process. Teams fix the symptom but never investigate the systemic cause.

The word "blameless" is key here, and it's harder than it sounds. When a deploy goes wrong at 2am and the on-call engineer has been up for four hours, the natural human instinct is to find fault. "Who approved this change?" "Why wasn't this caught in review?" But blame shuts down learning. John Allspaw, former CTO of Etsy, pioneered the blameless post-mortem because he understood that humans make errors — and the system either catches those errors or it doesn't. The system is what you fix.

The best post-mortems read like detective stories. They reconstruct a precise timeline, identify the root cause chain (not just the proximate cause), quantify the blast radius, and produce action items with owners and deadlines. If your post-mortem doesn't change something, it was just paperwork.

How This Prompt Helps

This prompt structures a blameless post-mortem from your incident details. You provide the severity, timeline, and impact data — and it produces a document with incident summary, detection and response timeline, root cause analysis using the "5 Whys" framework, impact assessment, and prioritized action items with owners.

The "5 Whys" section is particularly valuable because it pushes past the surface-level explanation. "The database crashed" becomes "the database crashed because connection pooling was misconfigured, because the config was copied from staging, because we don't have environment-specific config validation."

When to Reach for This

• An incident just happened and you need to document it while the details are fresh
• You're establishing a post-mortem culture on a team that has never done them before
• A recurring issue keeps happening and you need to find the systemic root cause
• Leadership is asking "how do we make sure this never happens again?" and you need a structured answer
• You want a template your on-call rotation can use consistently across incidents

What Good Looks Like

A strong post-mortem has a timeline accurate to the minute, a root cause analysis that goes at least three levels deep, an impact assessment with real numbers (users affected, revenue lost, SLA implications), and action items that are specific, assigned, and time-bound. The tone is curious, not accusatory. It reads like a learning document, not a blame document.

Sources

• PagerDuty Post-Mortem Guide — PagerDuty
• Blameless Post-Mortems and a Just Culture — Etsy Code as Craft
• Google Cloud Incident Reports — Google Cloud