Skip to content
Writing Style Library

Postmortem

A blameless retrospective of an incident: what happened, why, the impact, and the changes that keep it from happening again.

Postmortem

Section titled “Postmortem”

A postmortem is a structured account of a failure, near-miss, or significant service degradation. It traces what happened, when, and why - not to assign blame but to surface the systemic conditions that allowed the event to occur. Done well, a postmortem converts a painful episode into institutional knowledge that makes the system safer and the team more resilient.

The canonical postmortem separates timeline from analysis. A precise, time-stamped timeline lets reviewers reconstruct the sequence of events without relying on disputed memory; the analysis sections then ask why each link in the chain failed, following the chain until it reaches a systemic root cause rather than a human one. The blameless posture is not a courtesy - it is epistemically necessary: when individuals fear blame, the candid detail that reveals the real cause goes unspoken.

Postmortems earn their place when they end with concrete, owned, time-bound action items. A postmortem that catalogues what went wrong without committing to change is archaeology, not learning. The action items are the contract the team makes with itself to close the gap between the world as it was and the world as it should be.

Canonical template

Section titled “Canonical template”
# Postmortem: [Incident Title]


## Severity
[SEV-1 | SEV-2 | SEV-3 | SEV-4]


## Summary
[2-3 sentences: what broke, when, and the blast radius.]


## Timeline
- HH:MM UTC - [event]
- HH:MM UTC - [event]


## Root Cause
[The systemic condition that allowed the incident to occur. Follow the chain past the proximate trigger.]


## Impact
- Users affected: [count or percentage]
- Duration: [start] to [end]
- Services affected: [list]


## Contributing Factors
- [factor]


## Action Items
- [ ] [Specific change] - Owner: [person/team] - Due: [date]


## Lessons Learned
[What the team now knows that it did not know before.]

When to use

Section titled “When to use”

After a production incident, service outage, or significant near-miss; when a team needs to convert a failure into shared institutional knowledge; to produce concrete, owned remediation commitments after an incident; when building a safety culture that treats incidents as systemic signals rather than individual failures; communicating transparently with stakeholders about what went wrong and what changes are coming.

When not to use

Section titled “When not to use”

Routine project retrospectives that have no specific incident to investigate; celebrating successful launches or milestones; documenting forward-looking design or architectural decisions.

Pairs well with

Section titled “Pairs well with”

operator, pragmatic-architect, candid, matter-of-fact, decision-log, problem-solution

Often confused with

Section titled “Often confused with”

adr: An ADR captures a significant decision and the reasoning behind it, typically at or near the time the decision is made. A postmortem investigates a failure that has already occurred; its output is root-cause analysis and action items, not a decision rationale. The adr looks forward from a decision point; the postmortem looks backward from a failure.

status-report: A status report gives a periodic snapshot of project health - what is done, what is at risk, and what comes next. A postmortem is bounded to a specific incident: it investigates what broke, why, and what changes will prevent a recurrence. Status reports are recurring and open-ended; postmortems are closed when their action items ship.

retrospective: A postmortem is incident-triggered and drives to root cause with a timeline and severity; a retrospective runs on a regular cadence regardless of outcome and examines the whole working process, not one event.

Tells

Section titled “Tells”
  • A blameless framing that names systemic root causes rather than individual errors
  • A precise, time-stamped event timeline that reconstructs the sequence of the incident
  • A root cause statement that follows the chain past the proximate trigger to a systemic condition
  • An impact section that quantifies blast radius: users affected, duration, services degraded
  • Action items with named owners and due dates, not vague process aspirations
  • A lessons-learned section that states what the team now knows that it did not before

Anti-patterns

Section titled “Anti-patterns”
  • Assigning blame to an individual instead of tracing the systemic conditions that made the failure possible - Blameless postmortems surface the real cause; blame-forward ones stop at the nearest human and leave the systemic gap intact.
  • Writing action items as vague process aspirations such as “improve monitoring” without named owners or due dates - Unowned, undated action items are wishes, not commitments; they evaporate and the gap the incident exposed stays open.
  • Skipping the timeline and jumping straight to root cause and action items - The timeline is where contested memories get reconciled and hidden contributing factors surface; omitting it loses the evidence the analysis rests on.
  • Writing the document as a status update covering ongoing project health instead of a specific incident investigation - That slides into the confusable status-report format; a postmortem is always anchored to a specific, bounded incident, not ongoing project state.

Failure modes

Section titled “Failure modes”
  • Forensic over-reach - the root-cause chain is drilled so deep that the document becomes a months-long audit that no one reads and no action items ship - Stop the chain when you reach a systemic condition you can actually fix; flag the next layer as a separate lower-priority item and ship the action items you have.
  • Blamelessness tips into false neutrality - every contributing factor is so softened that the document avoids naming what specifically broke and the action items have no teeth - Blameless means no named individuals bear fault, not that the document avoids naming the specific system, process, or decision that failed; be precise about what broke, even when it is uncomfortable.

Instruction

Section titled “Instruction”
Write as a blameless postmortem. Use the canonical structure: Severity, Summary, Timeline,
Root Cause, Impact, Contributing Factors, Action Items, Lessons Learned. In the Timeline:
list events in chronological order with timestamps; be precise about what was observed, not
what was assumed. In Root Cause: follow the causal chain past the proximate trigger to the
systemic condition that allowed the incident to occur - name systems, processes, and decisions,
not people. In Action Items: every item must have a named owner and a due date; vague
aspirations do not count. Do not soften findings to the point that the document avoids naming
what broke. Blameless means no individual fault - it does not mean imprecise.

Template

Section titled “Template”

See the Postmortem template.

Section titled “Related”

Pairs well with

Section titled “Pairs well with”

Operator, Pragmatic Architect, Candid, Matter of Fact, Decision Log, Problem-Solution

Avoid with

Section titled “Avoid with”

Playful, Celebratory, Pastoral, Reverent

Often confused with

Section titled “Often confused with”

Architecture Decision Record, Status Report, Retrospective

Examples

Section titled “Examples”

Postmortem: Synchronous Standup Information Silo - Q1 Coordination Failure Pattern

Section titled “Postmortem: Synchronous Standup Information Silo - Q1 Coordination Failure Pattern”

Severity

Section titled “Severity”

SEV-3

Summary

Section titled “Summary”

Between January and March, the engineering team lost an estimated 11 engineer-hours across three separate incidents in which an engineer independently reworked a problem that had already been solved and discussed in a prior standup. The most recent incident occurred on March 18 when an engineer spent 3.5 hours debugging a caching edge case that the UK team had resolved and discussed verbally two days earlier. No written record of that solution existed. This postmortem investigates the systemic conditions that produced this pattern across the quarter and documents the commitments made to close the gap.

Timeline

Section titled “Timeline”
  • Mar 16, 09:14 PST - During the synchronous standup, two UK engineers describe a caching edge case fix they shipped overnight. No one documents the solution after the call. The fix does not appear in the ticket, the PR, or any channel message.
  • Mar 16, 09:28 PST - Standup ends. No recording is shared or transcribed. No follow-up action item captures the solution for engineers who were not present.
  • Mar 18, 10:05 PST - A US Eastern engineer encounters the same caching edge case in a different service. Having missed the March 16 standup due to a conflicting appointment, the engineer begins independent investigation with no knowledge of the prior fix.
  • Mar 18, 13:38 PST - After 3.5 hours of investigation, the engineer opens a Slack thread describing the problem. A UK teammate responds within four minutes: the problem was solved Monday, here is the approach.
  • Mar 18, 13:42 PST - Duplicate work is confirmed. Engineering manager identifies this as the third Q1 incident matching the same pattern and opens a process review.
  • Mar 18, 14:15 PST - Engineering manager pulls Q1 attendance data: India-based engineers attended an average of 3.2 of 5 weekly standups, US-based 4.6. The attendance gap correlates directly with missed verbal context.

Root Cause

Section titled “Root Cause”

The synchronous standup model produced no persistent record of solutions, resolved blockers, or context shared in the meeting. When a solution was discussed verbally, the only path for that knowledge to reach engineers who missed the standup was human memory or informal follow-up - neither of which was systematic. The standup was functioning as a real-time broadcast with zero persistence, not as a coordination system.

The proximate trigger for each Q1 incident was a missed standup attendance. The systemic condition was the absence of any mechanism - technical or process-based - that caused standup-shared knowledge to remain accessible to engineers not present on that call. Three separate incidents in one quarter were not anomalies; they were the expected output of a coordination model that treated verbal exchange as sufficient documentation.

Impact

Section titled “Impact”
  • Engineers who lost time to duplicate investigation: 4 across 3 Q1 incidents
  • Estimated engineer-hours lost to redundant investigation: 11 (Q1 aggregate)
  • Duration of pattern: January through March
  • Services affected: coordination across the full 11-person team; disproportionate impact on engineers outside US Pacific, who had the highest miss rate and no fallback for verbally shared context
  • Attendance gap that drove exposure: India-based engineers attended 3.2 of 5 standups on average, US-based 4.6. The gap is not behavioral; it is structural - the standup ran at 9:30pm IST.

Contributing Factors

Section titled “Contributing Factors”
  • No process required engineers to document solutions or resolved blockers after verbal discussion in standup
  • The meeting had no persistent artifact: no notes, no recording, no automatic transcription
  • The 14-minute standup averaged 4.2 minutes of actionable signal; the format created the appearance of coordination without the substance for engineers not in the room
  • Timezone asymmetry gave engineers with the highest miss rate the least access to verbally shared context
  • The failure mode was invisible: duplicate work looked like ordinary slow progress until engineers compared notes

Action Items

Section titled “Action Items”
  • Replace the synchronous standup with async posts in #team-standup per ADR-0014 - Owner: Engineering manager - Due: Trial start date
  • Add a “resolved blockers” field to the async standup template so solutions are documented at the source, not only in memory - Owner: Engineering manager - Due: Trial start date
  • Audit the three Q1 incidents; update each relevant ticket or PR with the solution that was shared only verbally - Owner: Tech lead - Due: Two weeks from this postmortem
  • Add a recurring agenda item to the Thursday working session to surface duplicate-work near-misses during the trial period - Owner: Engineering manager - Due: First Thursday session

Lessons Learned

Section titled “Lessons Learned”

A standup that creates no persistent record does not coordinate a distributed team; it coordinates only the subset of engineers who attended on that specific day. The Q1 incidents were not bad luck or lapses in individual communication. They were the predictable output of a coordination system with no memory. Coordination artifacts must be persistent and searchable by default, not as a quality-of-life improvement but as a prerequisite for the coordination to have actually occurred. When this team misses that bar, the cost is invisible until it is not.