01
Create one technical view
Start with impact, affected path, last known good state and current evidence. Separate observations from explanations. A dashboard, customer report and server metric can all be true without sharing the same cause.
One owner maintains the timeline and causal model so specialists can investigate without producing competing incident narratives.
02
Assign decisions, not activity
Every active thread should have an owner and a decision it is meant to support: rollback, isolate a dependency, challenge traffic, drain a queue or wait for more evidence.
More parallel activity is useful only when the results can change the next action.
03
Keep recovery reversible
Prefer interventions with a known rollback and a narrow blast radius. Record the state before the change and the signal that will decide whether to keep it.
A reversible mitigation can restore control before the full root cause is known. That is not a shortcut when uncertainty is explicit.
04
Close with system work
After recovery, preserve the timeline, the failed guardrail and the smallest structural change that prevents amplification. Assign follow-up work separately from the live incident.
A post-incident document should make the next responder faster, not prove that the previous responder was right.