Write up the incident.

Say what actually told you, and how long after the incident began. If a customer told you, write that a customer told you.

Customer support ticket, 14 minutes after the first failed checkout. No alert fired.

The issue was identified and the team responded quickly.

Why the weak one costs you. Whether an alert fired or a customer called is the fact that predicts your next incident, and it is the one people soften hardest, because it is the one that feels like an admission. It is not: every mature team has incidents their monitoring missed. What a reader distrusts is a review where detection is described in the passive voice, because that is where a missing alert is usually being hidden, and once they suspect that, they stop believing the rest of the document too.

From the first customer-visible effect to the first human who knew, not to the alert that fired later.

14 minutes (first failed checkout 09:02, support ticket 09:16)

Quickly

Why the weak one costs you. This is the number you can actually move. Time to mitigate is dominated by the specific problem and varies wildly between incidents, but time to detect is a property of your monitoring, so it is comparable across incidents and improving it shortens every future one. Recording it as a word rather than a number means you can never plot it, and a trend nobody can plot is a trend nobody manages.

To the point where customer impact stopped, which is usually earlier than the point where you understood the cause. If those are different, say both.

3h 41m to restore checkout. Cause confirmed a further 2h later.

Resolved same day

Why the weak one costs you. Mitigation and understanding are different clocks, and conflating them flatters the response. Restoring service by failing over is a good outcome and should be recorded as one, even when the diagnosis took all afternoon. Merging them into one number also hides the case worth knowing about: service restored fast by a change nobody understood, which is a repeat incident waiting for its trigger.

Quantify what you can. Then state plainly what you cannot determine and why, which is usually a retention limit or a gap in logging.

All checkout attempts failed for 3h 41m; 1,840 attempts by 612 accounts. No evidence of data access. Request logs retain 7 days, so access before 2026-08-12 cannot be ruled out either way.

Minimal customer impact; no data was compromised.

Why the weak one costs you. Two different claims are being made in the weak version and only one of them can be supported. "No evidence of access" is a finding. "No data was compromised" is a conclusion your logs cannot support, and asserting it is how a review becomes a liability: if something surfaces later, the document proves you overstated. Stating your retention limit costs you nothing, is the honest position, and is what makes a reader believe the numbers you do assert.

One line per moment that changed what someone did or believed. Include the theories you pursued and dropped, and name who did what.

09:41 | Rolled back the deploy on the theory it was the migration; no effect | Priya S.
10:20 | Found the pooler holding stale connections; restarted it | Priya S.

09:41 | Investigated
10:20 | Fixed the issue

Why the weak one costs you. A timeline containing only correct actions is a press release, and everyone reading it knows real incidents do not go that way. The dropped theory is the most useful line in the document: it is where the 40 minutes went, and it tells the next responder which plausible-looking answer to skip. Naming who did what is not about blame, it is what lets someone ask a follow-up question later, and a record where every action is passive is one nobody can learn from.

List several, each with the evidence a reader could check. Favour the conditions that were already true before the trigger, because those are the ones still present tomorrow.

Pooler config not covered by the migration checklist | Checklist v3 has no pooler step
No alert on checkout success rate | Alert catalog has latency and 5xx only

Root cause: engineer ran the migration without checking the pooler.

Why the weak one costs you. Singular root causes are almost always an artifact of stopping the search at the first plausible answer, and when that answer is a person, the search stopped early and pointed at the least changeable part of the system. The useful factors are the latent ones: the missing checklist step and the missing alert were both true the day before, will still be true next week, and each is fixable. Requiring evidence next to every factor is what keeps this from becoming a list of opinions, and it lets a reader weigh your analysis rather than take it on trust.

Name the things that worked, especially the ones you would have expected to fail.

Failover to the replica worked first time, unrehearsed since Q1

(left blank)

Why the weak one costs you. Two reasons this is not padding. Internally, a review that only ever lists failures teaches people that raising an incident is a punishment, and under-reporting is a far more expensive problem than any single outage. Externally, a control that demonstrably worked under real conditions is evidence in its own right, and this is usually the only place it is ever written down. Leaving this blank throws away the strongest material in the document.

One line per decision, with the clock it was made against and where that clock comes from. Record the decisions not to notify the same way.

Affected customers | 2026-08-19 18:00 | MSA 24h clock from confirmed impact
Regulator | Not notified | No personal data involved; assessed by Dana K. 2026-08-19

Customers were notified.

Why the weak one costs you. The decision not to notify is the one that gets questioned later, and it is the one almost nobody writes down, because at the time it feels like a non-event. Recorded with its basis and its assessor, it is a defensible judgement made on the facts available. Reconstructed a year later under scrutiny, it is indistinguishable from an oversight. This single field is the reason a lawyer will want this document to exist.

One named person per action, never a team, and a real date. Put at least one detection improvement in the list, not only the fix for this specific fault.

Add checkout success-rate alert | Priya S. | 2026-09-05

Improve monitoring | Platform team | ASAP

Why the weak one costs you. An action owned by a team is owned by nobody, and "ASAP" sorts to the bottom of every backlog, so the weak version reliably produces no change at all and the same incident recurs. Note also which action was chosen: fixing this specific fault stops this specific fault, while the detection improvement shortens every future incident of any cause. Reviews that only ever produce fault-specific fixes are why time to detect never improves.