Incident

After the incident is over, the value lives in what you decide to change. A postmortem that assigns blame gets a defensive team; one that asks “what can we change so this does not happen again” gets durable improvement. Blame kills the honest report The moment anyone asks ‘who is to blame’ the room quiets and the timeline shortens. People retell only what makes them look safe, so the record loses the decisions nobody wants to own. A blame-free report treats the timeline as a fixed record of what happened and treats people as the working part of a system with real constraints, not as its cause of failure. ...

During an incident, memory is unreliable and the clock is not. A timeline — who was paged, what was observed, what was tried, when the change landed — is what makes a response recordable and later reviewable. 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.