Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Mitigation vs Root Cause
Engineers want to understand before acting, because acting without understanding feels unprofessional. During an incident that instinct costs users directly: you do not need to know why the new version is failing to know that the old one was not. The mirror confusion is treating mitigation as resolution — impact stopped, ticket closed, nothing learned — and the third is the phrase "root cause" itself, which implies a single one. Real incidents have contributing factors, and picking one to be "the" cause conveniently ends the investigation before it reaches anything systemic.
Mitigate during the incident: stop user impact by any safe means — roll back, flip a flag, shed load, fail over, scale out.
Analyse afterwards, when nobody is losing money and you can be honest about contributing factors instead of the first plausible explanation.
| Dimension | Mitigation | Cause analysis |
|---|---|---|
| When | During the incident | After impact has stopped |
| Goal | Stop user impact | Change the system so this class of failure is less likely or less severe |
| Acceptable evidence | Correlation is enough to act on | Correlation is not enough to conclude |
| Typical action | Roll back, flag off, fail over, shed load | Guardrail, signal, default, test, design change |
| Fails by | Being mistaken for resolution | Stopping at one cause, or at "human error" |
| Output | Service restored, timeline recorded | Contributing factors and action items with owners |