01

Preserve a recoverable state

Record the current deployment, recent changes, affected URL, error time, and last known working behavior. Where the host permits it, keep a rollback point before editing. Do not delete logs, rotate every dependency, or combine the incident with a broad redesign.

02

Measure the customer impact

Determine whether the failure affects every visitor or one role, one device, one browser state, one route, or one provider event. That distinction narrows the cause and helps prioritize a site-down incident differently from an isolated administrative inconvenience.

03

Make one accountable repair

The implementation changes the smallest responsible layer and documents why it owns the failure. Production verification uses safe test data and checks related paths so the repair does not restore one screen while breaking another user role or follow-up event.

04

Separate recovery from improvement

After the live path is stable, performance work, refactoring, content improvement, or platform migration can be assessed with clearer evidence. Recovery should not become a pretext for selling an unnecessary full rebuild.