On-call handover: a checklist and template

A handover passes two things to the next person: the pager and the context. The rotation in the on-call tool moves the pager automatically at the handover time. The context only passes if the outgoing person writes it down or says it. Google's SRE Workbook describes the routine in two lines: at the start of each shift, the on-call engineer reads the handoff from the previous shift; at the end of the shift, they send a handoff email to the next engineer (Google SRE Workbook, On-Call). This guide covers what goes in that note, when to write it, and what the incoming person checks first. For rotation patterns themselves, see on-call rotation patterns.

What to hand over

The PagerDuty incident response guide states that you should give the next on-call engineer a quick summary of issues that may arise during their shift. This includes services that have been flapping or issues likely to recur (PagerDuty, Being On-Call). In practice, the note covers seven things.

• Open incidents and alerts. List each one with its status, owner, and next step. State plainly who owns an incident that is still being worked. The PagerDuty guide says that if you were paged for an issue during your shift, you are responsible for resolving it, even if it takes 3 hours and there is 1 hour of your shift left. You can hand it to the next on-call if they agree, but never assume they will.
• Silences, snoozes and maintenance windows in place. Note what is muted, why, and when it expires. A snooze can land on the next person. In PagerDuty, when a snooze expires and a different user has come on call since the incident triggered, both users are notified (PagerDuty, Edit Incidents). In Opsgenie, when a snooze ends the alert is treated as just received, and whoever is on call at that moment is notified (Opsgenie, Snooze an alert). See silences and maintenance windows.
• Noisy or flaky alerts. Identify which alerts fired without a real problem, how often, and whether a ticket exists. The SRE Workbook puts it this way: no one wants to be paged for the same issue that paged their teammate in the previous shift.
• Scheduled changes in the next shift. Include deploys, migrations, maintenance, certificate renewals and vendor maintenance, with an owner and a rollback link for each.
• Known risks. List anything running without its usual redundancy, a fix that needs watching, or a capacity limit that is close.
• Overrides and swaps already arranged. Note who covers which hours of the next shift. See on-call overrides and shift swaps.
• Follow-ups. Record tickets opened, postmortems due, and runbooks that were wrong.

When to hand over

Hand over at the rotation's handover time, the moment the tool moves the pager. A note written hours earlier misses the last part of the shift. A note written the next day arrives after the incoming person has already been paged.

• Pick a working-hours handover time, such as Monday 10:00, so the handover can be a conversation. A midnight handover means nobody talks. State the time with its time zone in the schedule and in the note.
• Use the tool's reminder. PagerDuty's on-call handoff notifications alert you up to 48 hours before you go on or off call, by push notification or email only (PagerDuty, Notification Rules). The "going off call" reminder is a good prompt to start the note.
• Put the backup shift after the primary shift. The PagerDuty guide recommends that a backup shift come directly after a primary shift. The previous primary then passes on context from their shift, and it discourages sitting on issues so the next shift has to fix them.

Sync or async

Always write the note. Add a conversation when the shift was eventful.

Situation	Handover
Quiet shift, nothing open	Written note only
An incident is still open or a risky change is scheduled	Written note plus a short call before the handover time
The incoming person is new to the rotation	Written note plus a call, and the outgoing person stays reachable for the first hours
A weekly team rotation	Written note plus an optional weekly handover meeting

The PagerDuty guide says a written report by email is the formal option and that a verbal summary is generally sufficient. A written note is better as a default, because it survives the call and the incoming person can reread it at 03:00.

GitLab's handbook shows one written process at scale. The outgoing engineer on call records the shift in a handover issue from a template and assigns it to the incoming engineer. A Slack command creates the issue and pre-fills the outgoing and incoming names, open and closed incidents, and resolved alerts. A weekly handover meeting, optional to attend, reviews the on-call report, open issues with the on-call label and 7-day graphs, and assigns all open on-call issues to the next on-call team (GitLab Handbook, On-call handover).

A handover template

Copy this into the team channel, a ticket or an email. Delete empty headings rather than writing "none" under every one, but keep "Open incidents and alerts" even when it is empty, so the incoming person knows it was checked.

On-call handover: <team or service>
Outgoing: <name>   Incoming: <name>
Shift: <start date time> to <end date time> <time zone>

Open incidents and alerts
- <link> <summary> | status: <triggered/acknowledged> | owner: <name> | next step: <action>

Silences, snoozes and maintenance windows in place
- <alert or matcher> | reason: <why> | expires: <date time time zone> | ticket: <link>

Noisy or flaky alerts this shift
- <alert name> | fired <n> times | real problem: <yes/no> | ticket: <link>

Scheduled changes in the next shift
- <date time> <change> | owner: <name> | rollback: <link>

Known risks
- <risk> | what to watch: <dashboard link>

Overrides and swaps in the next shift
- <date time range> <who covers>

Follow-ups
- <ticket, postmortem or runbook link>

Pages this shift: <count>, out of hours: <count>

The last line feeds the rota review. Count pages as well as shifts, and how many came at night.

What the incoming person checks first

1. You are on call. Open the schedule and confirm your name is on it now. An override can change who is on call without anyone editing the rotation.
2. Your notifications work. Send a test notification to each contact method. PagerDuty has a Test button next to each contact method in your profile (PagerDuty, Contact Information). For a full end-to-end check, see how to test an escalation policy.
3. Read the note and the open alert list. Compare the two. An alert that is open in the tool but missing from the note is a question for the outgoing person now.
4. Check what expires during your shift. Silences, snoozes and maintenance windows that end while you hold the pager can notify you if the problem is still there.
5. Check scheduled changes. Know what is being deployed or migrated and who to call if it goes wrong.
6. Check access. The PagerDuty guide lists the basics: laptop and internet with you, environment set up, repositories working locally, and credentials for third-party services current.
7. Know where the runbooks are and how to escalate. See runbooks.
8. Ask questions while the outgoing person is still around. After the handover time they are off duty.

Common gaps

• Unclear ownership of an open incident. A note stating "still looking into it" lacks direction. Specify who owns the incident next and what action they will take.
• A snooze that wakes the next person. Snoozing an alert until morning shifts the burden to the incoming engineer. They receive the alert without context. List every snooze and its expiry time.
• A note nobody reads. Post the handover note where the incoming engineer will see it. Address the note to them directly. GitLab assigns the handover issue to the incoming engineer for this reason.
• Handing over the same noise every week. Fix or delete a flaky alert if it appears in three consecutive handovers. See alert fatigue.

Tools with schedules, handover reminders and overrides are in the on-call directory.