Hand off a long incident without resetting the investigation

A good incident handoff transfers the current decision state, not a transcript. The outgoing responder should update one live record with impact, system state, active mitigations, disproved hypotheses, risky operations, owners, and the next decision deadline, then walk the incoming responder through it before responsibility changes.

Lead with impact and control

Start with what users experience, when it began, affected regions or tenants, and the best current measurement. State who is incident commander, operations lead, and communications lead. Google’s Incident Response chapter emphasizes clear command, defined roles, a working record, and structured coordination. A handoff that does not name the new owner leaves everyone assuming someone else is watching.

Record whether impact is growing, stable, or declining and which signal supports that judgment. Include current service versions, recent changes, dependency state, capacity, and data-integrity concerns. Link dashboards with fixed time ranges so the incoming responder sees the same evidence rather than a refreshed view that has shifted.

Preserve decisions, including negative results

For each hypothesis, write the observation that suggested it, the test performed, the result, and whether it is disproved, weakened, or still open. “Database checked” is useless. “Primary database CPU normal in all affected regions; failover did not change error rate; database saturation is unlikely” prevents repetition and preserves reasoning. Do not mark a theory disproved when the test covered only one region or path.

List every mitigation that is active or staged. Include exact scope, start time, owner, expected signal, rollback trigger, and reversal command or runbook. Highlight commands that must not be repeated, such as a non-idempotent replay or one-time failover. If credentials or sensitive values are involved, reference their secure location rather than copying them.

The Google SRE guide to accelerating engineers to on-call stresses structured learning, system understanding, realistic exercises, and the ability to reason through unfamiliar failures. A consistent handoff record supports the same skills during a live event: the incoming responder can reconstruct the system boundary and decision tree instead of relying on personal memory.

Set the next decision point

End with no more than three immediate actions. Each needs an owner and a deadline: evaluate rollback when the current canary reaches 5,000 requests; page the storage owner if replication lag exceeds the agreed threshold; publish the next status update at 14:30 UTC. Include pending approvals and the person authorized to make them.

Run the handoff as readback. The incoming responder states impact, current mitigation, largest unresolved risk, and next decision in their own words. The outgoing responder corrects gaps, the commander announces the role transfer, and the old owner remains available for a short overlap when feasible. Chat remains supporting evidence, not the canonical state.

Use a compact live template

The record needs sections for impact; roles and contacts; current system state; changes near onset; mitigations; hypotheses and evidence; risky or irreversible actions; next decisions; and communication commitments. Timestamp edits and preserve prior versions, but keep the front page current.

Practice during a game day. Midway through the scenario, replace the operations lead and give the successor only the handoff record plus a five-minute readback. Note every question the record could not answer and revise the template. The next real handoff should continue mitigation from the same decision point rather than restart investigation.

Capture uncertainty explicitly

Separate facts, interpretations, and unanswered questions. A graph rise is a fact; that a deployment caused it is a hypothesis. Give confidence and scope to each conclusion, and note missing telemetry. During readback, ask which claim would most change the mitigation if false. Record abandoned mitigations and why they were rejected. This lets the incoming team challenge inherited assumptions without repeating completed work or unknowingly reviving an unsafe proposal.

Reviewed September 2026.