On-Call Handover Checklist
An on-call handover checklist for DevOps and SRE shifts: open incidents, noisy alerts, risky changes, access and paging checks, so nothing gets lost in the gap.
- Typical schedule weekly
- The checklist 4 sections, 17 items
- Variables
{{incoming_engineer}}{{week}}
Use this checklist at every on-call rotation change, typically weekly. It is meant for a short handover conversation of 15 to 30 minutes between the outgoing and incoming engineer, ideally on a call rather than a chat message. The handover is when context is most easily lost. An open incident or a half-done risky change can then catch the next person by surprise at night.
Who owns it
The outgoing engineer owns the run and prepares the notes. The incoming engineer checks the access and paging items themselves, because only they can confirm that their own phone actually rings. Once the run is complete, responsibility has formally moved.
Common pitfalls
- Handover by chat message only. A written summary is good, but a short conversation surfaces the things people forget to write down, such as "this alert is flaky, but don't ignore it on Tuesdays".
- Assuming paging works. Phones change, apps get logged out and do-not-disturb settings block calls. Send a test page to the incoming engineer.
- Hidden ongoing work. Silenced alerts, temporary fixes and scheduled maintenance must be passed on explicitly, with an end date.
- Burnout signals ignored. If last week was rough, say so. A team lead may need to rebalance the rotation or fix the noisy alerts.
Schedule the run in Runbook for the rotation change. Over time, the history becomes a simple weekly log of on-call load.
The checklist: On-call handover to {{incoming_engineer}} ({{week}})
Review the past shift
-
Incidents from the past shift listed with status and links
-
Open incidents and their current owner passed on explicitly
-
Pages and alerts from the shift reviewed, with noisy or flaky alerts named
Create tickets for alerts that fired without needing action, so they get fixed or removed.
-
Postmortems that still need to be written assigned
Ongoing work and risks
-
Temporary fixes and workarounds still in place listed, with how to undo them
-
Silenced or muted alerts listed, each with an end time
-
Planned deploys, maintenance and migrations during the coming shift reviewed
-
Known risks shared: capacity close to limits, expiring certificates, vendor issues
-
Customer escalations or support tickets that may need engineering passed on optional
Access and readiness
-
{{incoming_engineer}}is set as primary on call in the paging tool -
Test page sent to
{{incoming_engineer}}and received on their phone -
{{incoming_engineer}}can reach production: VPN, SSO, bastion and cloud console -
Secondary on call and escalation contacts confirmed for the coming shift
-
Planned absences or time-zone gaps during the shift covered optional
Close the handover
-
Handover notes written in the team channel or on-call log
-
Outgoing engineer's shift load noted, and the team lead informed if it was heavy
-
Outgoing engineer removed as primary on call
Checklist as Markdown
Frequently asked questions
What should be included in an on-call handover?
Cover open incidents, recent alerts and which of them are noisy, temporary fixes, silenced alerts, planned changes and known risks. The incoming engineer should also confirm that paging and production access work for them. A short written note plus a brief conversation works best.
How long should an on-call handover take?
For most small teams, 15 to 30 minutes is enough. After a busy week with open incidents it can take longer, and that is a good sign that the handover is doing its job. Schedule it at a fixed time so both engineers are available.
Should the handover be synchronous or asynchronous?
A synchronous call is better for questions and nuance, especially when there are open issues. Teams spread across time zones often write the notes asynchronously and add a short call when something is in progress. In either case, the incoming engineer should confirm the handover explicitly.
Updated