A Postmortem Template Engineers Actually Read
A short incident postmortem template: what happened, what still constrains you, and what to do next time. Plus a filled-in example.
Most postmortem templates are long because they were designed to be complete. Timeline, impact, root cause, contributing factors, what went well, what went poorly, lessons learned, action items, appendix. Teams fill them in. The next time a related alert fires, nobody opens the document, because it takes twenty minutes to find the one paragraph that would have helped.
Write the postmortem for the engineer who is under pressure later. They need to know what broke, what is still true about the system after the fix, and the first checks to run if it happens again. Everything else is optional.
The template
If a section would be empty, delete it. A short record that someone will reread beats a complete one that lives in a folder.
# Short title
Date:
Severity:
Author:
## What happened
Two or three sentences. What broke, who noticed, how it ended.
## Impact
Who was affected, and for how long.
## Timeline
All times in the timezone you operate in.
- HH:MM what we saw
- HH:MM what we did
- HH:MM recovered
## What still constrains us
The fact about the system that is still true after the fix.
This is the paragraph the next person needs.
## Do this next time
The first checks, in order.
## Follow-ups
- Action. Owner. Due.A filled-in example
# Nightly billing job ran twice
Date: 2026-03-02
Severity: SEV-2
Author: Priya
## What happened
A deploy overlapped the cron window. The nightly billing job started
on both app servers and some customers were charged twice. We refunded
the duplicates and shipped a lock so a second copy exits.
## Impact
About 40 customers, one night. Charges were reversed the next morning.
No data loss.
## Timeline
Times in AEST.
- 02:06 Deploy finished during the billing window
- 02:11 Two job runs visible in the logs
- 07:40 Support tickets started
- 11:20 Refunds issued, lock shipped in PR #482
## What still constrains us
The job must not run on two servers at once. The lock is held by the
database connection, so a hung job keeps it until the connection dies.
That is acceptable while billing runs once a day.
## Do this next time
1. Check whether two copies of the job logged a start.
2. Do not rerun billing until you know which customers were charged.
3. Refunds are a billing-team action, not a support-team action.
## Follow-ups
- Advisory lock around the job. Priya. Done in #482.
- Alert if the job skips. Unowned. Not needed while it retries next night.What to leave out
A lessons-learned essay restates the timeline in the abstract. Skip it unless the lesson applies to a different system than the one that broke. A root-cause section that ends at "human error" is a stopping point, not a conclusion. Name the condition that let the person make that mistake: the deploy was allowed during the cron window, and nothing stopped the second copy.
Keep the tone blameless because blame makes the next writeup vaguer, and vague writeups are the ones nobody trusts. Name systems, conditions, and actions. The follow-ups need an owner. A follow-up with no owner is a wish.
Keep the lesson on the system
Prodigent attaches the incident to the service and the people involved, so the constraint shows up the next time that code changes.
Try Prodigent free