What the next shift needs
An incident handover should let the incoming engineer continue safely without reconstructing the whole chat. Put the current customer impact and the time of the last observation first. Distinguish a confirmed fact from a working hypothesis.
Copy this structure
- Status and impact: affected service, geography or customer journey, start time and current severity.
- Evidence: links to the incident channel, dashboards, relevant logs and the exact time window. Restrict access to sensitive material.
- Timeline: changes, symptoms and actions in chronological order, including who made them.
- Current hypothesis: what supports it, what contradicts it and what is still unknown.
- Next actions: named owner, expected result, decision deadline and rollback or stop condition.
- Communication: last stakeholder update and when the next update is due.
Preserve the decision boundary
Mark commands as completed, planned or rejected. If a restart temporarily reduced errors, say so rather than claiming it fixed the cause. Record any running migration, backup or failover and the person authorized to stop it. Do not paste passwords, tokens or customer data into the handover.
The incoming and outgoing responders should overlap long enough to verify ownership, access and the immediate next step. A short verbal walkthrough helps, but the written record remains necessary for anyone joining later.
Close the loop
After stabilization, capture recovery evidence, customer communication and follow-up tasks. Assign each task an owner and review date. A useful handover reduces uncertainty; it does not replace an incident commander or an organization-specific escalation process.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.