How to write a blameless postmortem from a timeline
The hard part of a postmortem is rarely the analysis. It is rebuilding what happened, in order, from a chat scroll and three dashboards while memory is still fresh. Do that first, and the discussion can be about the system instead of who remembers what.
The four numbers
Time to detect — start of impact to the first alert or customer report. A large number here points at monitoring, not at responders.
Time to acknowledge — detection to a person taking ownership. Points at paging and on-call routing.
Time to mitigate — start to the first rollback, failover or workaround that reduced impact. Usually the number users feel.
Time to resolve — start to the all-clear. Averaged over many incidents this is MTTR.
Steps
Copy timestamped lines from chat, the pager and your deploy log into one list. Include the boring ones: who joined, what was checked.
Tag the lines that define the phases (start:, detected:, acknowledged:, mitigated:, resolved:) if wording alone is ambiguous.
Look at the silent gaps first. Thirty minutes with nothing logged usually hides a question: what was being tried, or what was nobody able to see?
Write impact in terms of users and time, not blame. Name roles and systems rather than individuals.
Ask why until you reach a missing guard, alert or runbook step. Each becomes an action item with one owner and a date.
For repeated incidents, add node postmortem.mjs incident.txt --max-ttr 60m to a script to track resolution against a target.
What this does not tell you
It measures only what was written down, and it guesses phases from wording. The draft leaves root cause, impact and action items to your team. It is a starting point and not professional advice.