An engineer ran a command that deleted production data. What does the postmortem investigate?

What is being tested

Whether you investigate the system rather than the person — not out of kindness, but because the alternative produces no usable information.

What the postmortem investigates

Not "why was the engineer careless". The operating assumption is that people act reasonably given the information and constraints they had. So:

• Why did the system permit it? Why did a single command have that blast radius? Why was production reachable from wherever the command ran?
• Why was the consequence not obvious? Was there a confirmation? Did it state what would be affected and how much? Was the environment visually distinguishable from staging?
• Why was it not recoverable? This is usually the most important question. Data deletion that is instantly recoverable is an inconvenience. The severity came from the recovery gap — no soft delete, no recent backup, an untested restore, a restore measured in hours.
• Why was the engineer doing this manually at all? A manual production data operation is itself the finding. What tooling was missing that made this the available path?
• What was the pressure? Was this during an incident? Under time pressure? At 3am? Those conditions are systemic, not personal.
• How long until it was detected, and how? If a customer reported it, the detection gap is a finding in its own right.

Why blameless is a mechanism, not a nicety

If an engineer believes the postmortem could damage them, they will describe the incident in a way that protects them. The account will be technically true and materially incomplete, and the actual cause — which is almost always systemic — will not surface.

Beyond that: the specific person will not make this specific mistake again. Everyone else still can. Fixing the person fixes one instance; fixing the system fixes all of them.

What the action items should look like

Ranked, owned and dated, and skewed toward:

• Reducing blast radius — scoped credentials, production access requiring elevation, commands that cannot address everything.
• Making consequences visible — confirmations stating the affected count, distinct environment styling.
• Improving recoverability — soft deletes with a retention window, tested restores, point-in-time recovery. This usually yields the most value per unit of effort.
• Removing the manual path — tooling that does the task safely.
• Reducing detection time.

The prioritisation insight

Teams instinctively focus on preventing the specific trigger, which is often the least likely thing to recur. The reusable improvements are in detection, diagnosis and recovery speed.

Reducing time-to-detect from 18 minutes to 2 improves every future incident, including all the ones with causes nobody has imagined. Preventing this exact command improves one.

What else belongs in the document

Impact in user terms ("34,000 users could not check out for 22 minutes", not "the cache tier was degraded"). A timeline whose gaps are examined. Contributing factors, plural — serious incidents never have a single cause, and the root cause is a stopping rule rather than a discovery. And what went well, including luck explicitly labelled as luck, because you cannot rely on it twice.