Incident postmortem collector
A small system that assembles an incident timeline from what actually happened, holds a write-up that describes contributing conditions rather than a single cause, follows the action items to closure or to an honest abandonment, and surfaces relevant past incidents when a new one starts. Seven posts on the same system, one diagram at a time, with a cost breakdown and an engineering reference at the end.
- 01
An incident postmortem collector on AWS for a few dollars a month
The whole system on one page — timeline, write-up, actions — and the observation that the value of a postmortem is realised entirely on re-reading.
- 02
How the timeline gets assembled while it is fresh
How memory distorts an incident timeline, capturing events as a by-product of working, why beliefs matter more than facts, and what to capture automatically.
- 03
Why there is rarely one root cause
Why a single root cause is usually the trigger rather than the cause, how contributing conditions are identified, why blame is an analytical failure as well as a cultural one, and what the write-up should contain.
- 04
What happens to the action items
Why postmortem actions go unclosed, why declining is a legitimate and useful outcome, how many actions is right, and what the open count does to participation.
- 05
How old postmortems get read again
How past incidents are surfaced automatically, what makes two incidents similar, the near miss that never gets written, and the recurrence pattern only visible in aggregate.
- 06
What the incident postmortem collector costs
About $1 a month. One Bedrock read per incident is the only line that grows; the queue, the table, the mail and the storage are rounding errors. Plus the three ways the bill could surprise you.
- 07
Engineering reference: the incident postmortem collector architecture
Same system, drawn purely for engineers. Service names, region, Lambda inventory, IAM scopes, the schemas and the exact model id.
Frequently asked questions
- What is an incident postmortem collector?
- A small serverless system that captures incident timelines while they are fresh, holds the write-up, tracks the resulting actions, and makes past incidents findable when they are relevant.
- Why not identify a root cause?
- Because incidents rarely have one. A single named cause is usually the last thing that changed, and stopping there hides the conditions that let it become an incident.
- What happens to postmortem action items?
- In most organisations, nothing, which is why they get their own post. An action nobody intends to do should be closed as declined rather than left open forever.
- Who is a postmortem written for?
- The people who were not there, including people who join in two years. That audience changes how it should be written.
- What does it cost to run?
- A couple of dollars a month. See part six.