One field consistently missing from on-call handoff notes: the muted alert. A complete handoff must cover active incidents, silenced alerts and upcoming deploys - what's muted, why, when it expires, and any risky changes the incoming engineer should know about. Most handoff notes nail the first category and skip the second entirely. That gap is where blind-spot incidents are born.
A 2025 Splunk study found that 73% of organizations experienced outages linked to ignored alerts. Some of those ignored alerts were noise. Others were legitimate signals that someone muted during the previous shift and never passed on. The incoming engineer never knew they existed.
This is a playbook for writing the on-call handoff message in Slack - the one that posts at rotation time, requires two minutes to fill out, and gives the incoming engineer a real picture of system state instead of just the headline incidents.
What belongs in an on-call handoff Slack message
The handoff note answers one question: what does the incoming engineer need to know right now that they cannot see on a dashboard? That shapes exactly five sections.
A handoff checklist should cover active incidents, muted alerts with reasons, ongoing investigations, pending items, contact info for key stakeholders, and any context about recent changes or deployments. Translate that into a Slack message with this structure:
Section 1: Active incidents Each open incident gets one line: ticket ID, current status, one-sentence summary of where it stands, and next action. Not a novel - just enough for the incoming engineer to pick up the thread.
- Format:
[INC-1234] API latency elevated - memory leak patched Monday, watch for recurrence through deploy on Wednesday - If it is truly resolved: say so and drop it
Section 2: Muted / silenced alerts This is the section most notes skip. The outgoing engineer often assumes the incoming engineer already knows the current workaround or mitigation. They do not. For every muted alert: name it, say why it was silenced, and note when the silence expires.
- Format:
disk-usage-warning on prod-db-02 - muted until Wednesday 09:00 UTC, migration running, will auto-resolve - If nothing is muted: say "No active silences" explicitly. The absence of the section creates ambiguity.
Section 3: Upcoming risk window Any deploy, migration, or configuration change scheduled in the next 48 hours that could produce alerts. The incoming engineer should not discover these by getting paged.
Section 4: What to watch One to three specific things that are not incidents yet but felt wrong during the shift. A queue depth creeping upward. A retry rate that spiked once and dropped. This is the tacit knowledge that lives in the outgoing engineer's head and dies there unless written down.
Section 5: Escalation contacts
Escalation contacts go stale because a manager, vendor, or resolver changed recently. Paste the current names and handles - do not link to a doc that might be out of date. If the primary escalation contact changed this week, say so.
The format that keeps it short enough to actually fill out
Handoffs fail when they rely on memory. Create a shift report at the end of every rotation, even quiet ones. The trap is making the template so thorough that filling it out takes 20 minutes. Engineers skip long templates under pressure.
The Slack message format that sticks is a pinned template in the #on-call channel - five headings, each starting with a bold label, each expecting no more than three bullet points. The outgoing engineer fills in bullets, deletes the placeholder text, and posts. Under two minutes on a quiet shift; five minutes on a heavy one.
Here is the minimal working template: