On-Call Handover Checklist
A shift-change ritual that transfers full context on open incidents, active mitigations, fragile services, and upcoming changes, with verified tool access for the incoming engineer. Everything is captured in a shared on-call log to build institutional memory.
When to Use This Checklist
Use this checklist at every on-call shift change, and especially across weekends, holidays, or time-zone boundaries where the next responder has less ambient context. A handover is a small ritual with outsized value: it prevents the incoming engineer from rediscovering, under pressure, problems the outgoing engineer already understood.
How to Use This Checklist
Run the handover as a short, focused conversation backed by a written summary. The outgoing engineer walks the incoming one through open incidents, active mitigations, and any temporary changes that will need reverting. Both confirm the incoming engineer actually has access to the tools they will need, because the worst time to discover a broken login is mid-incident.
Keep a shared on-call log. Writing the summary down means context survives even if the conversation is rushed, and it builds an institutional memory of recurring issues.
What Good Looks Like
A clean handover leaves the incoming engineer with no surprises. They know which services are fragile, what mitigations are propping things up, and which deployments or maintenance windows fall in their shift. Their access to alerting, dashboards, runbooks, and break-glass paths is confirmed, not assumed. Error-budget status and any change freeze are understood, so they know how cautious to be. The whole exchange is captured in a shared log that the next handover can build on.
Common Pitfalls
The most common failure is a handover that happens only verbally, or not at all, leaving the incoming engineer blind to active mitigations and temporary hacks. Another is assuming access works; tooling permissions drift, and a responder who cannot acknowledge a page is no responder at all. Teams also forget to flag known-fragile services, so the new engineer treats a precarious situation as normal until it breaks.
Related Resources
Pair this with on-call and incident-management best practices, and use SLO and error-budget status to communicate how much risk the shift can absorb.