Run an On-Call Handoff
Transfer on-call responsibility with current incidents, risky changes, capacity notes, alert noise, and explicit ownership so nothing depends on memory.
Objective
Give the incoming on-call engineer the context needed to detect, diagnose, and escalate incidents without repeating the outgoing engineer's investigation.
Environment
- A shared incident tracker and alert dashboard
- A handoff document or channel with a stable template
- Access to deploy history and planned changes
Steps
1. Summarize active and recent incidents
List open incidents, their current state, the next expected action, and who owns each. Include recently resolved incidents that may recur.
Expected state: The incoming engineer knows what is still broken and what to watch.
2. Review changes in the handoff window
List deploys, feature flags, migrations, certificate expirations, and planned maintenance during the next shift.
Expected state: Every risky change has an owner, a rollback path, and a time window.
3. Transfer alert context
Call out noisy alerts, known false positives, silenced alerts, and dashboards that are currently misleading.
Expected state: The incoming engineer does not re-investigate a known false alarm or miss a silenced real one.
4. Confirm access and escalation
Verify the incoming engineer can access dashboards, logs, deploy tools, and the escalation roster, and knows who to call for each dependency.
Expected state: A page can be investigated and escalated without waiting for the outgoing engineer.
5. Record the handoff
Post the handoff in the shared channel, tag the incoming owner, and note the next handoff time.
Expected state: Ownership is explicit and time-bounded.
Decision points
Should an ongoing incident block the handoff?
- Hand off with a joint call and explicit transfer
- Delay the handoff until the incident is resolved
Hand off during a stable phase with a joint call; delay only when the incident is actively changing and the outgoing engineer has unique context.
How much detail should the handoff include?
- Only open incidents and alerts
- Incidents, risky changes, capacity, access, and known noise
Include all five; most surprises come from changes and noise, not from the incident already being worked.
Expected outcome
The incoming engineer starts the shift with an accurate incident picture, change awareness, working access, and a named escalation path.
Verification
Ask the incoming engineer to restate the top three risks and the first action for each; confirm they can open the dashboards and run the rollback command from the runbook.
Cleanup
Close stale handoff items, update the runbook with new alerts or failure modes, and archive the handoff note.
Handoff is a risk transfer
The outgoing engineer carries context that is not in any dashboard: a deploy that looked fine but is still being watched, an alert that fires on a known false positive, a dependency contact who is on vacation. The handoff makes that context explicit. Without it, the next engineer starts from zero during an incident.
Handoff 2026-10-20 09:00 UTC
Open: INC-142 checkout latency, mitigated, watching error rate
Changes: orders-api deploy 1.8.3 at 08:10, rollback flag orders_v2
Risks: certificate for webhooks expires 10-22, renewal ticket OPS-88
Noise: DiskSpaceWarning on node-7 is a known cron artifact
Escalation: DB -> @dba-oncall, payments -> #payments-engDo not rely on memory
A handoff that is only a verbal conversation is lost when the shift ends. Post it in a stable channel, tag the incoming owner, and link the dashboards and tickets. The template should be short enough to complete and specific enough to act on. Avoid dumping raw alert history; summarize what matters.
Verify, do not assume
Access is a common handoff failure. The incoming engineer may have the role but not the deploy permission, or the runbook may reference a tool that moved. Ask them to open one dashboard and run a read-only command from the runbook. This takes a minute and catches missing access before an incident.
Feed the runbook
Every handoff that reveals a new failure mode, noisy alert, or missing access should update the runbook. The handoff is not only a transfer; it is a lightweight review of operational readiness. Over time, the runbook becomes the durable memory of the rotation.