After an incident, a postmortem should explain what happened, what people knew at the time, and which changes could reduce future harm. Blamelessness makes candid reporting safer. It does not guarantee that an incident cannot recur, remove ownership, or turn every explanation into an established fact. Learning requires both an honest account and evidence that useful follow-up actually happened. ...
During an incident, memory is unreliable, and clocks can disagree too. A timeline — who was paged, what was observed, what was tried, when the change landed — is what makes a response recordable and later reviewable. Times and actors are transcribed from the inert source fixture. The shared date and UTC offset are display shorthand; underlying entries require full timestamps. Vertical spacing is schematic, not elapsed-time scale. A planned effect is not shown as a confirmed fix; no validator or incident system was run. Write as it happens Memory is the least reliable instrument in an incident, so record while the alert is fresh. Capture the timestamp of the first alert, the initial symptoms, each action tried and its observable result, and the moment the fix actually took effect. That running record is what keeps a team from repeating a failed fix during the response, and what later makes an honest postmortem possible instead of a plausible story. Make the timeline a live document from the minute the page fires: note the tool that alerted, the metric, the suspected and the confirmed cause, and record ‘same as before, did not help’ rather than silently re-trying. ...
A postmortem is a chronological map from detected symptom to verified fix, backed by the commands that produced each fact.