Midnight is the most popular time to hand off an on-call shift in PagerDuty's scheduling data. It's the most common handoff slot - and the one PagerDuty itself recommends against, because it's the time least likely to allow a real conversation between outgoing and incoming engineers. That gap between what teams do and what actually works is, in miniature, the whole problem with on-call handoffs.
The note itself compounds it. Most teams have a template that covers open incidents and maybe a few recent deploys. Almost none of them document silenced alerts - the suppressed pages that the outgoing engineer muted three days ago, fully intending to re-enable, and then forgot. The incoming engineer inherits a quiet pager. On Tuesday afternoon, a service that should have fired doesn't.
What belongs in an on-call handoff note
The note's job is to make the incoming engineer confident, not just informed. The purpose of the handoff is to make sure the incoming on-call responder has all of the information and context for the current state of the environment. That sounds obvious. The execution is where teams cut corners.
A complete handoff note has five sections:
| Field | What goes there | Why it gets skipped |
|---|---|---|
| Open incidents | PagerDuty/Linear links, current status, owner | Usually present - lowest bar |
| Silenced alerts | Every suppression with its expiry time | Not surfaced by most tooling |
| Recent deploys | Anything shipped in the last 48 hours, especially to dependencies | Engineers assume the incoming person saw the PR |
| Escalation contact changes | Anyone who left, is on leave, or changed roles | Treated as general knowledge |
| TODO debt | Alerting noise, runbook gaps, workarounds in place | Deferred because it feels optional |
PagerDuty's own ops guide specifically calls out recent deployments on key systems including upstream dependencies and downstream consumers, queued remediation work from postmortems, and any action items to improve documentation, alerting, or context for the next person.
A clean handoff is the difference between a confident on-call engineer and one who walks into a minefield. A structured 30-minute transition - covering active incidents, silenced alerts, and upcoming risky changes - is sufficient.
The silenced alerts row is the one almost nobody fills in, and it's the one that causes the most post-handoff incidents. When an outgoing engineer silences a noisy alert, that context lives in their head: "this fires every Monday because of the batch job." Details in playbooks - and handoff notes - go out of date at the same rate as production environment changes. For daily releases, they might need an update on any given day. The incoming engineer doesn't know what's been suppressed unless you write it down at the moment of handoff.
Why the note is a forcing function, not just a document
Here's the non-obvious part: the handoff note is not primarily for the incoming engineer. It's for the outgoing one.
At the end of an on-call shift, responders should have an on-call review meeting. Practicing a proper on-call handoff gives the team an opportunity to learn directly from the responder coming off the shift. The meeting allows the team to catch problems before they become trends.
The act of writing forces the outgoing engineer to enumerate everything they muted, deferred, or silently worked around. Most of those things were not forgotten through negligence - they were deprioritized under pressure. For SRE teams, on-call duties typically account for 25% of their time.
On-call engineers typically allocate 30-40% of their bandwidth during an on-call period to incident responsibilities. When you're managing live incidents, todo debt accumulates fast.
The primary purpose of the on-call review is to understand the on-call load for the shift, identify sources of pain, transfer knowledge between responders, and plan for improvements of future shifts.
The problem is that when the handoff note is a manual document - a Notion page to copy, a Confluence template to fill - it competes with the urge to sign off and sleep. Teams skip it, or file a thin version. PagerDuty's State of Digital Operations (2024) shows median MTTR ranging from 22 minutes for highly automated teams to over 4 hours for manually-operated systems. The gap between those numbers isn't talent - it's how much context survives the handoff.
The average on-call engineer receives roughly 50 alerts per week, but only 2-5% of those require human intervention. The handoff note is the moment to audit which of the remaining 95%+ have been silenced, muted, or deprioritized - and whether that was intentional.
How to run the handoff in Slack
Schedule the weekly handoff as a standing meeting - 30 minutes, Monday morning. Both outgoing and incoming engineers present. Cover active incidents, silenced alerts, and upcoming risky changes. Have the incoming engineer summarize back before the outgoing engineer signs off.
The part that breaks down in practice: the outgoing engineer has to write the note before the meeting, and they often don't. The note should live in the handoff channel, not a wiki. If it's in Slack, the incoming engineer can read it before the call, the team has a searchable record, and the draft can be automated.
Here's what that looks like:
Beagle in action#on-call-rotation, Friday 4:45pmThe draft doesn't replace the engineer's judgment on silenced alerts and escalation contacts - those require human input. But it removes the activation energy that causes people to skip the note entirely. A pre-filled skeleton with the factual fields already populated is much harder to abandon than a blank template.
The one field to add this week
If your current handoff template is missing the silenced-alerts section, add it before the next rotation. The field doesn't need to be elaborate:
- Alert name - which suppression rule or policy
- Suppressed since - the date/time it was muted
- Why - one sentence: known flap, scheduled maintenance, false positive under investigation
- Expiry - when it's set to re-enable, or "manual"
Runbooks and handoff notes should cover your top incident types specifically: specific commands, specific dashboards, specific escalation contacts. A runbook is a checklist, not a manual. The same principle applies to the handoff note - specific and actionable, not vague and reassuring.
PagerDuty recommends making the second layer of your escalation policy the engineer from the prior week, since they still have context from any previous incidents. That design only works if the outgoing engineer actually wrote down what they know.
On-call handoff notes: common questions
What should be in an on-call handoff note?
An on-call handoff note should cover five things: open incidents with current status and links, silenced or suppressed alerts with expiry times, recent deployments in the last 48 hours, any changes to escalation contacts, and outstanding todo items from the shift. Most templates only include the first and third. The silenced-alerts field is the highest-risk omission.
How long should an on-call handoff meeting take?
Thirty minutes is enough for most teams. The meeting works best when the incoming engineer has already read the written note beforehand, so the call is a verbal confirmation and Q&A - not the first time the context is being transferred. Both engineers should be present, and the incoming engineer should summarize back before the outgoing one signs off.
When is the best time to hand off an on-call shift?
Business hours, when both parties are available and alert. Midnight is the most common handoff time in PagerDuty scheduling data, but it's also the worst time for an actual knowledge transfer. Monday morning overlaps most weekly sprint rhythms and gives the incoming engineer a full day to get oriented before the week's peak activity.
Where should the handoff note live?
In your on-call Slack channel, not a wiki. A wiki page requires the incoming engineer to know it exists and where to find it. A pinned or posted Slack message is visible in the channel the team already monitors, searchable by the whole team, and easier to link back when a post-incident review asks what was known at handoff.
How do you handle handoff notes for follow-the-sun rotations?
Follow-the-sun rotations need a written note every shift boundary, not just weekly. FTS's largest strength - distributed workflow - is simultaneously its largest weakness. Distributed teams face higher coordination complexity, and every shift transition magnifies the risk of missing critical context. For FTS teams, the five-field structure above applies at every regional handoff, and silenced alerts become even more critical because the incoming region has no ambient context from the day's conversations.