The Incident Post-Mortem Template for Small Teams

An incident that ends without a written post-mortem will happen again. Not because your team is careless — because memory decays, the people who were there move on, and the fix that lived in someone's head quietly retired with them. A post-mortem template is the difference between paying for an incident once and paying for it on a subscription. This is the one-page version a five-person team can actually finish in an hour — not the twelve-section enterprise ritual that gets abandoned by section three.

1. The 48-hour window

Write the post-mortem within 48 hours of resolution, while the timeline is still retrievable and the feelings have cooled enough to be useful. Past 48 hours, the logs rotate, the chat scrolls away, and two people will remember the order of events differently — and neither will be wrong enough to notice. The rule that works: the incident commander (or whoever closed the ticket) books a 45-minute post-mortem slot before closing the incident. If it is not on the calendar before the all-clear, it does not happen.

2. Blameless is a format, not a feeling

Blameless does not mean nobody was involved — it means the document interrogates systems, not people. The test is simple: every sentence in the contributing-factors section must survive having the person's name replaced with the role. "The on-call engineer forgot to extend the certificate" becomes "the certificate-expiry check had no calendar escalation, so a renewal task could silently expire." The first version teaches nobody anything. The second version is a fix you can ship. You are not writing an alibi — you are writing the design change that makes the mistake structurally hard to repeat.

3. The one-page structure: six fields, no more

The whole post-mortem fits on one page. Six fields:

Summary — two sentences: what broke, who noticed. "Checkout returned 502s for 34 minutes after the payment gateway rotated keys. First customer report at 03:12; monitoring page at 03:19."
Impact — numbers, not adjectives. Orders failed, revenue lost, customers affected, minutes down. "11 orders failed, ~$480, 41 customers saw errors."
Timeline — UTC-stamped events from first trigger to verified fix (see section 4).
Contributing factors — the five whys output (section 5).
What went well — the parts of the response that worked. This field is not decoration; it tells you what to protect when you change the system.
Action items — each with an owner, a due date, and how you will verify it closed (section 6).

One page forces ranking. If it does not fit, you have two incidents, not one.

4. Rebuild the timeline from logs, not memory

Memory gives you a story; logs give you a timeline. Pull events from four sources and merge them by UTC timestamp: the alerting system (what fired, when, with what latency), the application/service logs (the actual failure moments), the chat channel (decisions and handoffs — "03:41 decided to roll back"), and the deploy/change log (what changed in the 24 hours before — this is where most causes hide). Every line gets a timestamp and an event; no line gets a name with an adjective attached. "03:07 config deploy #4821 applied" — not "03:07 someone pushed a bad config."

5. Five whys — but stop at the fixable layer

Ask "why" five times, writing each answer down. Stop the chain at the first layer you can actually change this month. Below that, you find physics, vendor economics, or headcount — true, but not actionable, and a post-mortem that ends at "we need more staff" changes nothing. Example: the disk filled (why) because log rotation failed (why) because the rotation config was overwritten (why) by a deploy that shipped its own config (why) because there is no check that deploys preserve ops config. That last layer — a pre-deploy config check — is shippable in a day. "We need a better server" was the layer-zero answer that would have guaranteed the repeat.

6. Action items that actually close

An action item is not a wish. It has four fields: what (one concrete change), owner (a name, never "the team"), due date (a real date inside 30 days), and verification (how you will know it closed — "the check fires in staging," not "we discussed it"). The honest ratio: if fewer than 80% of last quarter's action items closed on time, your post-mortems are producing paperwork, not prevention. Put the open action items in the weekly ops review until they close. An action item still open at 30 days gets re-decided, not silently renewed — either it matters enough to do or it mattered enough to write down why you are not doing it.

7. The read-out and the archive

Two closes, both cheap. The read-out: five bullets to whoever was not awake for it — what broke, impact, root cause, the fix shipped, the fix pending. This goes in the channel everyone reads, not a meeting nobody attends. The archive: the post-mortem file lives in the repo next to the runbook it changes, named YYYY-MM-DD-short-name-post-mortem.md. Before the next incident, the responder greps this folder — half the time the incident you are fighting has a predecessor with its fix already written down. Six months of archived post-mortems is the cheapest runbook library you will ever build.

A worked example: the Tuesday 3 a.m. disk-full

A three-person team's checkout dies at 03:10 on a Tuesday. The on-call clears the disk in nine minutes and — because the template was booked before the all-clear — files the post-mortem the next morning. Summary: log rotation failed, disk hit 100%, checkout 502 for 9 minutes. Impact: 3 orders failed, ~$140. Timeline rebuilt from alerts and deploy log: 02:50 deploy shipped an overwriting logrotate config; 03:04 disk alert fired to an unmonitored channel; 03:10 first customer error; 03:19 on-call paged by a customer tweet; 03:29 disk cleared, verified. Five whys land on "no deploy check preserves ops config." Action items: config-preservation check in CI (owner: the on-call engineer, due Friday, verified by a red test in staging); disk alert re-routed to the main channel (due Wednesday, verified by a test alert); runbook updated with the rotate-now command (done same day). Three weeks later a near-identical deploy runs — and the CI check rejects it in 40 seconds. The repeat cost: one red build instead of one outage.

Incident Response Drill Schedule Template — rehearse before the real one writes the post-mortem for you
Disk-Full Incident Runbook — the worked cause of this template's example incident
Uptime & Downtime Budget — how many minutes your tier actually allows
Runaway Automation Runbook — when the system that broke is one you built
Daily Ops Audit Checklist — where the ten-minute check catches the next one early
Postmortem Template for Small Teams — the fill-in cousin for project, move, and season close-outs (this page owns incident reviews)

An incident is tuition; the post-mortem is the receipt that proves you learned something. Write it inside 48 hours, keep it to one page and six fields, interrogate systems instead of people, close the action items like tickets, and archive where the next responder will look. Small teams that write post-mortems stop having the same incident twice — small teams that skip them get to have it again, with feeling.

The meeting that fills this document in — the 45-minute format, the participant list, the ground rules, and the five blame traps that produce silence instead of truth — is the blameless post-incident review template.