On-Call Handoff Notes in Slack Are Missing One Thing

Most on-call handoff notes cover open incidents. The thing that actually causes the next problem is what got silenced, and why. A field playbook for tighter Slack handoffs.

Cover art for On-Call Handoff Notes in Slack Are Missing One Thing

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?

5%reopen rate targetresolved incidents reopened within 4 hours of shift change
30 minminimum handoff timefor a straightforward shift - 60 min for complex operational states
37%MTTR reductionreported by teams with structured on-call tooling and Slack-native escalation

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:

  1. One channel per rotation week, archived after Friday retro - or a persistent #oncall-handoffs channel with pinned notes per shift.

  2. 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.

  3. Use a thread for the overlap conversation. The note is the source of truth; the back-and-forth lives in replies.

  4. 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.

Beagle in action#oncall-handoffs, Sunday 4:45pm
The ask
outgoing engineer posts: 'shift ends at 5 - anything I missed?'
Beagle drafts
reads the week's #incidents thread, pulls open issues, silenced alerts, and the deploy calendar; drafts a structured handoff note with five sections
You approve
engineer reviews in 90 seconds, adds one line about a cert renewal, hits approve - note posts with a source link to each referenced incident
Do this in your workspace →

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:

Or just watch me work

Point me at your website.

I will read up on your business and come back with what I would run for you. No account, no card, about a minute.

I only read what is public. Nothing is saved to your name until you say so.

Keep reading

Beagle does this work for you, in your Slack.1,000 free credits. No card.Hire Beagle