Counterfactual Reasoning in Incident Analysis
Counterfactual reasoning asks what would have prevented or mitigated an incident: if this alert had existed, if this check had run. Used well it finds systemic gaps, but it is a trap when it implies a single person should have just acted differently in…
WHY IT EXISTS Understanding an incident is not only about what happened but about what could have changed the outcome. Counterfactual reasoning exists to systematically probe those alternatives so the team can identify safeguards that were missing and would meaningfully prevent or shrink a recurrence.
THE MENTAL MODEL Think of replaying the incident while changing one variable at a time and asking whether the outcome improves. If an alert had existed on this metric, would detection have been faster. If a rate limit had been in place, would the cascade have been contained. The useful version targets the system and its controls; the harmful version targets a person, asking why didn't you just notice, which is hindsight bias dressed up as analysis.
HOW IT WORKS During analysis, for each phase of the incident you pose alternatives focused on mechanisms: detection, prevention, and mitigation. Good counterfactuals are grounded in plausible, implementable changes, such as an automated guardrail, a missing test, or a safer default, and they translate directly into remediation items. The discipline is to keep them blameless: phrase them about what the system lacked, not what an individual failed to do, because the responder almost always acted reasonably with the information available in the moment.
WHEN IT MATTERS It matters most in blameless postmortems, where the entire value depends on extracting systemic lessons without scapegoating. Done well, counterfactuals are an engine for generating preventive action items. Done poorly, they corrode psychological safety, discourage honest disclosure, and produce shallow fixes like telling people to be more careful, which never hold.
ONE CONCRETE EXAMPLE A harmful counterfactual: if the on-call engineer had checked the dashboard sooner, the outage would have been shorter. A constructive one: if an automated alert had fired on the queue depth that was already climbing, detection would not have depended on someone happening to look, so the action item is to add that alert. The second changes the system; the first just blames a person for not having foresight.
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.