Writing post-incident notes people reopen months later

Good post-incident notes behave like maps someone else can walk without you breathing over their shoulder. Start with a cold open: what customers perceived, what internal monitors showed, and where those stories diverged. That contrast gives future readers a reason to care before you dive into timelines. Second paragraph belongs to decisions, not drama. List the forks your team considered, the data each option leaned on, and the explicit trade-offs you rejected. When you omit rejected paths, you accidentally teach hero narratives instead of engineering judgement. Link to dashboards with dated screenshots so URLs do not rot silently. Third paragraph anchors follow-ups. Tie each action to an owner, a measurable signal, and a review date. If an action lacks a signal, it is a wish, not work. Close with a short reflection on what communication worked — maybe the quiet-room rule, maybe the scribe rotation — so facilitators inherit habits, not just tickets. Finally, acknowledge uncertainty. Name the hypotheses still unproven and the telemetry gaps that would have saved minutes. Readers respect honesty more than polished certainty, and it invites the next cohort to improve the template rather than copy-paste it.