Principle
Mitigate first when the incident is still hurting
The perfect explanation is not the first service you owe an active outage.
When it fits
- A live incident is causing material harm while a deeper diagnosis could take much longer.
When to avoid it
- Do not use mitigation-first as permission for uncontrolled production changes or evidence destruction.
Why it matters
Separate the immediate question—how to reduce impact—from the later question—why the failure happened. Choose a reversible mitigation such as rollback, traffic shift, feature disablement or workload reduction when it is safer than continuing damage. Preserve evidence and record what the mitigation changed so the later investigation still has a trail.
An example
Route new work away from a failing integration before tracing every condition that caused the backlog.
Check your result
User or system impact is measurably reduced, or the proposed mitigation is rejected for an explicit safety reason.
Keep this limit in mind
- Do not use mitigation-first as permission for uncontrolled production changes or evidence destruction.
Connected ideas
Use beforeMine postmortems for repeated failure patterns
Evidence and sources
Google SRE's incident-response guidance recommends a mitigation-first response before deeper investigation consumes the incident.
Mitigation should not destroy evidence, violate change controls or create a larger safety problem.
Incident Response · Incident Response Training