The first bad night of a rotation is often about something the previous engineer knew and did not write down. This free on-call handover checklist gives SRE, platform, infrastructure and MSP engineering teams a routine for every rotation change, whether the pager moves weekly or follows the sun between regions. The outgoing engineer prepares a written note, both engineers talk it through, the incoming engineer proves that paging and access work, and the pager moves only when they accept it. On weekly rotation changes, a short review of the rotation that just ended sends noisy alerts, runbook gaps and repeat failures to the people who can fix them.
Paging tools rotate the schedule automatically, so it is easy to believe the handover happens by itself. It does not. The schedule moves the alerts. It does not move the knowledge of what is fragile this week, what is half fixed and what is about to change. That has to travel from one engineer to another, and it travels best in writing plus a short conversation.
Google’s Site Reliability Workbook lists this among the basic duties of an on-call engineer: read the handoff from the previous shift when the shift starts, and send a handoff email to the next engineer when it ends. This checklist turns that habit into named tasks for each side, with a check that the incoming engineer can actually be reached before anyone relies on them.
Brings: the rotation log, open incidents, work left half done, silenced alerts and risky events coming up.
Common failure: a tired engineer writes “quiet week, nothing to report” while a manual fix is still holding a service together.
Done when: the note is written and every open item has an agreed owner.
Checks: a test page arrives on every method, VPN and consoles work, escalation contacts are current, runbooks open.
Common failure: the first real page at 03:00 is also the first time they discover their access expired.
Done when: they accept the handover and the paging tool routes to them.
The scope stops at the handover and the rotation around it. Running an incident, writing its postmortem and chasing its root cause each have their own process, and the handover only makes sure they have an owner. A staffed service desk’s working day is a different routine again, although the desk’s end-of-day notes are often one of the inputs here.
Phases 1 to 4 run at every handover. Phases 5 and 6 appear on rotation changes and stay hidden on daily follow-the-sun shift handovers. The pager does not move until the incoming engineer accepts it in Phase 4.
Done by the outgoing engineer before the call. The answers on the first task hide the incident and silenced-alert tasks when there is nothing to report.
Done by the incoming engineer. The last task appears only when they are new to this rotation.
The first task is an approval assigned to the incoming engineer named on the first task. The checklist halts there, and the outgoing engineer keeps the pager, until they record their decision.
Appears only on rotation changes. The outgoing engineer completes it with the rotation lead, often in the weekly operations meeting.
Appears only on rotation changes. The postmortem task appears only when the review records a significant incident.
A good note is short and specific. Each line below answers a question the incoming engineer would otherwise have to ask at the worst possible moment.
| Item | What to write | What goes wrong without it |
|---|---|---|
| Open incidents | Status, lead, next update time, what has been tried | The same diagnosis is repeated from scratch |
| Half-done work | What was changed by hand and how to put it back | A temporary fix becomes permanent by accident |
| Silenced alerts | Alert, reason, owner, expiry | A real failure fires into a silence nobody remembers |
| Known noisy alerts | Which ones page, why, and whether they can wait | A night lost to a fault that was already understood |
| Coming risky events | Date, time, owner, rollback contact | A 02:00 migration pages someone who did not know it existed |
| Ownership | Who keeps each open item after the handover | Follow-ups fall between two engineers and neither does them |
The rotation review needs a limit to compare against, and Google’s published figures are a useful reference point. The Site Reliability Engineering book’s chapter on being on call says an incident takes about six hours on average once root-cause analysis, remediation and follow-up are included, which is why it puts the ceiling at two incidents per 12-hour shift. The same chapter caps on-call work at 25% of an SRE’s time and suggests at least eight engineers for a single-site rotation, or six per site for a two-site one.
These are one company’s numbers for its own services, not a standard. They still make a sensible starting point: if your rotation regularly goes past two incidents a shift, the follow-up work is not getting done, and Phase 6 is where that shows.
A recurring schedule opens the handover at your rotation time, weekly or daily for follow-the-sun, and assigns it to the on-call group. The incoming engineer’s tasks go to the person picked on the first task, so each side sees only its own work.
The acceptance task halts the checklist until the incoming engineer records a decision. If a test page fails or access is missing, they record Not approved with the reason, and the outgoing engineer stays on until it is fixed. The activity trail shows the exact time responsibility moved.
Pages and silenced alerts go into tables inside the tasks, so the rotation review counts from real entries instead of memory. Conditional logic hides the review on shift handovers, and template versioning keeps a record of each question added after a handover missed something.
The handover passes work on; it does not do it. An incident still open at handover keeps running in the Incident Management Checklist, significant ones go on to the Incident Postmortem Template, and repeat failures found in the review become records in the Problem Management Checklist. Runbooks worth checking in Phase 3 are easier to write with the IT runbook template guide.
During working hours, the service desk runs its own routine in the IT Help Desk Daily Checklist, which ends by passing anything likely to page overnight to whoever holds the pager. CheckFlow’s recurring checklist software explains how the schedules, assignments and reminders behind both routines work.
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
Anything open or unusual that the incoming engineer could be paged about: incidents still running, work left half done, alerts that are silenced and when the silence ends, known noisy alerts that can wait, and risky events booked for the coming rotation. It should also confirm who owns each open item and who the secondary and escalation contacts are. The incoming engineer then checks that paging and access work before accepting.
A week is a common length: long enough for continuity, short enough to limit fatigue, and it keeps handovers to one a week. What matters more is the length of each shift within it. Google’s Site Reliability Workbook recommends limiting shifts to 12 hours for rotations that get paged every day, and describes 24 hours of on-call without a break as unsustainable. Teams with engineers in several regions often split each day between them instead.
A rotation shared between teams in different time zones, so each region covers its own daytime and hands the pager to the next region as its day ends. Google’s SRE book notes that it lets teams avoid night shifts altogether. The cost is more handovers: at least one a day per region, which is why a short, consistent checklist matters more here than on a weekly rotation.
Google’s SRE book puts the minimum at eight engineers for a single-site team and six per site for a team split across two sites, based on its cap of 25% of time spent on call, with a primary and a secondary always on call and week-long shifts. Smaller teams do run round-the-clock rotations, but each person is on call more often, and the rotation review is where you will see the cost in hours and sleep.
Google targets a maximum of two incidents per on-call shift, because each one takes around six hours once follow-up is included. Raw page counts matter less than whether each page was actionable; the SRE book says all paging alerts should be. Count both in the rotation review, and treat any page that needed no human action as a ticket to tune or remove that alert.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
