Your incident record isn't your postmortem

A monitoring tool's incident record gives you the skeleton of a postmortem: what failed, when, how severe, how many times. It does not give you the postmortem itself. The part that actually explains the incident, why it happened and what you decided to do about it, still has to be written by a person, and it only exists clearly in your head for about as long as it takes to move on to the next thing.

What the incident record already has

Most incident-tracking tools, WebPixie included, open a record automatically once a check confirms a problem, and close it automatically once the check recovers. Between those two events, the record accumulates structured facts without anyone typing anything: a status, a severity, which resource was affected, how the incident started (uptime failure, an SSL check failing, a certificate or domain approaching expiry, a domain entering a suspended state), and a timestamp on both ends. If the same problem keeps firing, it shows up as one incident with a rising occurrence count instead of a pile of separate alerts.

None of that required a human to write anything down. It's the automatic half, and it's genuinely useful: it tells you the shape of what happened and, roughly, how bad. See how WebPixie tracks incident status, severity, and occurrence count for the specifics.

What it doesn't have

The occurrence count tells you a problem repeated. It doesn't tell you what you thought was going on the first time it fired, or why you decided the second occurrence wasn't worth waking someone up for. The severity level tells you the tool classified this as HIGH. It doesn't tell you that you personally judged it worse than that because it happened during a traffic spike, or that you almost paged the wrong person because the alert routing looked ambiguous in the moment. None of that lives in a timestamp.

Google's own SRE book defines a postmortem as a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring. Impact, actions taken, and root cause are exactly the parts a monitoring tool's automatic record can't produce on its own. It can tell you the incident happened and roughly how long it lasted. It can't tell you why, and it can't tell you what you actually did about it in the moment, because that decision happened in your head, not in a request log.

Why this has a shelf life

The record itself doesn't decay. The timestamps stay accurate indefinitely. What decays is your own memory of the reasoning: which log line made you suspect the database before the CDN, why you ruled out the deploy that went out an hour earlier, what the on-call channel actually looked like before someone archived the thread. A week later you can still see that the incident opened at 14:32 and closed at 14:58. You've usually lost the part where you'd have explained why it took 26 minutes instead of 5.

This is the actual argument for writing something down close to the incident's closure, not the generic advice to do it quickly that every postmortem guide repeats. It's not about discipline. It's that the record and the reasoning decay on different timelines, and only one of them is backed up automatically.

A short list, not a template

Most postmortem guidance is written for teams already running a dedicated incident-management platform, PagerDuty, incident.io, or similar, where timeline assembly, contributor tagging, and review workflows are the product. If that's not your team, you don't need six-section templates or a review-tier matrix to get the value. You need to capture the part the tool can't, while it's still in your head:

• What you believed was happening at the moment you started investigating, even if it turned out wrong
• The specific signal that changed your mind, if it did
• Why you picked the fix you picked over an alternative you considered
• Who or what was actually affected, in terms a non-engineer would understand
• Anything you'd do differently if the same alert fired again tomorrow

Applied to a real incident: checkout returned 500s for 12 minutes. Believed at the time: the deploy that shipped an hour earlier. Signal that changed that: rolling it back did not stop the errors. Fix picked: restarted the exhausted connection pool instead of failing over regions, since the logs pointed at connections, not a regional outage. Affected: checkout was down for about 12 minutes, some customers likely saw failed payments. Next time: add an alert on connection-pool exhaustion instead of relying on the generic error-rate one.

That's five lines against the incident record, written once, right after closure. Attach it directly to the incident's own note if your monitoring tool supports one, so the reasoning sits next to the facts it explains instead of drifting into a separate doc nobody finds again. It's not a review process and it doesn't need an owner or a due date. It only needs to happen before the incident becomes a vague memory of "something broke that one week."

Where this still falls short

A severity level and an occurrence count are lagging signals. By the time a flapping endpoint has recurred twice, whatever context explained the first occurrence may already be gone, because nothing prompted you to write it down the first time. The record can flag that something recurred; it can't flag that you're about to lose the reasoning behind it. That part is still on you, and no amount of automatic tracking changes it.

If the incident didn't need a severity matrix to get classified in the first place, see why a fixed severity assignment can skip the matrix-design step entirely. Capturing what happened is the next problem, and it's a different one: no amount of automatic classification writes down what you were thinking.