Incident response

During an incident, the goal is stop the bleeding, not understand the bug. Those are different jobs and doing them in the wrong order extends the outage — the most common failure is a smart engineer debugging root cause while users are still down, when a rollback would have fixed it in ninety seconds.

Understanding can wait. Users cannot.

1. Establish impact before touching anything

Sixty seconds, no more:

• What is broken, for whom, how badly? All users or some? Degraded or entirely down?
• Is it getting worse? A steady failure and an accelerating one need different urgency.
• When did it start? Line this up against deploys and config changes immediately — this single question resolves a large share of incidents.

Done when: you can state impact in one sentence and have a start time.