Reviewing an incident from a meeting recording: postmortem template

Reconstruct the events first

After an incident, people remember different moments: spotting the issue, receiving a message later, or starting the fix. A coherent account can put events in the wrong order. Start with a verifiable timeline.

Run the postmortem after initial recovery, when the team can examine events calmly. The recording captures explanations. Cross-check event times against messages, logs, and other evidence. Keep internal data out of public reports.

Build the review in four parts

1. Describe the impact

   Identify the feature or operation that was unavailable, for whom, and for how long. Separate confirmed and possible impact. If the number affected is unknown, say so.

2. Build the timeline

   Capture onset, detection, reporting, first actions, and recovery. Include the time zone. When an event is known only from someone’s recollection, retain the source and confidence level. Mark approximate times as such.

3. Test the explanations

   Distinguish the immediate trigger from conditions that let the problem occur or persist. Ask what information was available at the time. Link each hypothesis to evidence and state what could disprove it.

4. Assign actions you can verify

   Choose actions that reduce a specific risk or speed up detection or recovery. Give each an owner, expected result, and way to check it. “Be more careful” identifies neither a process change nor a completion check.

Notifications for new requests stopped arriving

This fictional example uses names, conditions, and results solely to illustrate the method.

The requests remained available. Notification delivery failed. The distinction affects how you describe impact and choose actions.

The timeline is illustrative. It shows the gap between onset and detection. It does not establish the technical cause.

Postmortem template

Keep possible causes marked as hypotheses until evidence confirms them.

Incident, period, and time zone:
Confirmed impact:
Timeline: time / event / source:
Trigger:
Contributing conditions:
What worked during recovery:
What remains unknown:
Action / owner / deadline / verification:
When to review completion:

Check that the review helps prevent recurrence

• Impact is more precise than “everything broke.”
• Event times are distinct from the times they were discussed.
• Confirmed causes are distinct from unverified hypotheses.
• Each action addresses an observable problem and has a check.