Preserve the timeline.
Write down events in the order in which they were observed. Include the timezone, the beginning of the reported impact and the moment recovery was verified. A single timestamp without its source can be misleading: a dashboard, application log and external monitor may disagree.
Where possible, include the exact user-visible symptom. “The API was down” is less informative than “Requests to the health endpoint returned connection timeouts from two locations while local service checks remained green.”
Keep facts separate from explanations.
Operators naturally form hypotheses. The report should record them, but not silently turn them into conclusions. Use clear distinctions: observed, suspected, tested and ruled out. A short note that a suspected cause remains unproven can prevent a future engineer from treating the guess as established history.
Record what the system did before deciding why it did it.
Explain the decisions made under pressure.
Write why a restart, rollback or traffic shift was chosen, which alternatives were available and what signal indicated success. These details are useful precisely because the next incident may have a different trigger but the same operational constraints.
Include the recovery boundary: which state was restored and which parts of the system were not verified. A truthful partial recovery is more useful than a broad declaration that “everything is fixed”.
Finish with accountable next actions.
A long list of speculative improvements is not an incident follow-up. Select actions that address demonstrated failure modes, assign responsibility and describe the evidence that will show completion.
Where cause remains unknown, name the smallest observation that would distinguish plausible explanations. This keeps future work focused and prevents repeated broad experiments.