Postmortem

Write for learning

A useful postmortem gives readers enough detail to understand the incident without reconstructing it from scattered chat messages. Include a concise summary, timeline, impact, detection, response, contributing conditions, and follow-up actions.

Blameless language matters because incidents usually emerge from interactions among software, processes, tools, and decisions. “The engineer made a mistake” does not explain why the system allowed that mistake to create impact. A better account asks what information, guardrail, or feedback was missing.

Make the timeline evidence based

Use deployment records, alerts, logs, traces, and communication timestamps. Separate observed facts from hypotheses. Record when impact began, when responders recognized it, what mitigations were attempted, and when service returned to an acceptable state.

Turn findings into action

Follow-up work should have an owner, a clear outcome, and a reasonable priority. Actions might improve tests, rollout controls, alert quality, documentation, or service design. Track whether the change was completed and whether it reduced the original risk.

Weave adds engineering context to this process by helping teams inspect the changes and review patterns associated with an incident. The postmortem remains a shared learning document, not a scorecard for individuals.