It's Monday at 9 AM. The incoming engineer takes the pager, skims the handoff note, sees zero active incidents, and calls it clean. By 10:30 they're investigating a latency spike that the outgoing engineer had been watching - quietly, under a silenced alert that was supposed to expire Tuesday.
Outgoing engineers routinely assume the incoming engineer understands context they actually lack: "You know about the database issue," "Same stuff as usual," "Everything's fine" - when in fact it ignores subtle degradation. The Monday morning problem isn't missing information about open fires. It's missing information about what's been deliberately muted and why.
This is a field playbook for on-call handoff notes in Slack that actually transfer operational state - not just a list of open tickets.
What a complete on-call handoff note actually covers
A handoff note is complete when the incoming engineer can act from minute one without asking a single clarifying question. Most notes stop at "here are the open incidents." That is not a handoff - it's a status page.
Handoffs fail when they rely on memory. A complete shift report - even for quiet shifts - must cover active incidents with status and next steps, silenced alerts with their expiry and reason, upcoming risky deployments, and specific runbook and dashboard URLs, not a vague "check Datadog."
The five sections that matter, in order of how often they get dropped:
- Silenced alerts - what's muted, when it expires, and what triggered the silence. This is the single most commonly dropped item.
- Active incidents - current status, severity, and the actual next step (not "monitoring").
- Smoldering issues - degraded but not paging, trends worth watching, anything marked "keep an eye on."
- Upcoming changes - deploys, migrations, or maintenance windows scheduled in the next 24 hours.
- Escalation contacts - teams also miss escalation contacts that changed recently, or fail to confirm that the incoming engineer can reach the required systems.
Handoffs that only cover active incidents miss the broader operational picture. Incoming engineers need to understand the full context - not just current fires. A shift with zero open incidents can still be a dangerous handoff.
The one quality metric most teams don't track
Incidents marked resolved during one shift that get reopened by the next shift is a measurable handoff quality signal. Target: less than 5% of resolved incidents reopened within four hours of handoff. If your number is higher, the notes are not transferring enough state.
This is a genuinely useful SLO because it's directly observable in your incident tool or Slack history, and it forces the question: did the outgoing engineer actually resolve it, or just hand the problem to the next person wearing fresh eyes?
Manual escalation, tool sprawl, and missing context cause as much SRE fatigue as shift length. That's the part the rotation schedule alone cannot fix.
The Slack channel setup that keeps the note findable
Posting handoff summaries to a team channel automatically creates a searchable history and enables async input from team members.
The note should land in a dedicated channel - not buried in #general or threaded off an incident post where it disappears.
A workable pattern:
One channel per rotation week, archived after Friday retro - or a persistent
#oncall-handoffschannel with pinned notes per shift.Post the note 15-30 minutes before shift change. Sending written notes before the overlap window starts lets the incoming engineer formulate questions during review rather than discovering confusion mid-handoff, which maximizes the overlap window's effectiveness.
Use a thread for the overlap conversation. The note is the source of truth; the back-and-forth lives in replies.
Pin or bookmark the note so the incoming engineer can find it at 3 AM without scrolling.
GitLab's SRE team does this with a Slack command in their #production channel that automatically creates a handoff issue and pre-populates outgoing and incoming engineer handles, open incidents, and resolved alerts.
That's a concrete automation target - the note structure does not have to be manual.
Before you automate, fix the template
Automation drafting from a bad template produces a better-formatted bad note. Get the structure right manually first.
A minimal handoff template for Slack: