One team's postmortem put it plainly: the outgoing engineer left a Slack message at 11pm and went to bed. The incoming engineer had no idea what happened over the weekend. Two hours were lost every Monday just rebuilding context. That's not a bad week - that's the default when there's no real handoff structure. Extrapolate it: at 52 rotation changes a year, that's over 100 engineer-hours consumed by context reconstruction before anyone writes a single line of code.
The gap isn't laziness. A lot of teams think they have a handoff process because they have a rotation schedule, a Slack message, and a short note that says "nothing major is going on." That is not a real handoff. That is administrative transfer without operational context.
What a Slack on-call handoff message actually needs to contain
A useful on-call handoff message answers five questions the incoming engineer will ask within the first hour of their shift. State the answer first; add detail in the thread.
A complete handoff must cover: active incidents with current status and severity for anything unresolved; silenced alerts and upcoming deploys including what's muted, why, and when it expires; and specific runbook and dashboard URLs - not "check Datadog." Two more fields make the difference between a message that gets read once and one that actually prevents a 2am page:
- Watchlist - services that are degraded but not alerting yet. Most painful overnight incidents are not caused by a total lack of monitoring; they are caused by partial awareness. A queue was already growing, a database failover looked slightly unstable, a partner API had started timing out intermittently. If the outgoing engineer noticed it, it belongs in the message.
- Escalation context - who to call for what, beyond the generic on-call page. Every escalation level must map to a specific person. An escalation policy ending at a generic email address ensures alerts die unnoticed.
Here's the five-field structure as a Slack message format:
| Field | What to include | What to skip |
|---|---|---|
| Active issues | Status, next step, ETA | Resolved items from more than 48h ago |
| Silenced alerts | Which alert, why muted, expiry time | Alerts that are supposed to fire |
| Watchlist | Service name, symptom, threshold to watch | Anything already in a runbook |
| Upcoming risk | Deploys, cert expiries, traffic events | Routine scheduled jobs |
| Escalation contacts | Named people, not team aliases | On-call rotation tool links |
Post the five fields in the main channel message. Put supporting links, dashboards, and full incident timelines in the thread.
Why the outgoing engineer keeps skipping it
The transition between on-call shifts is a critical point where context can be lost. But the reason it keeps happening has less to do with intent and more to do with timing. The outgoing engineer is usually writing the handoff message at the moment they most want to stop thinking about the shift - end of Friday, middle of the night, right after resolving something draining.
Purpose-built tools for structured shift handoffs are an underdeveloped category. Most engineering teams have no dedicated tool for this - they use Slack, Notion, or nothing.
The non-obvious consequence: because the handoff is authored under cognitive load at the worst possible moment, the outgoing engineer defaults to what's freshest in memory - the last incident - and forgets the slow-burn risks that haven't paged anyone yet. Those are exactly the items that cause 2am surprises.
Beagle in action#eng-oncall, Friday 5:47pmThe 15-minute handoff meeting that changes the outcome
One team had three dropped incidents in a single quarter due to poor handoffs. They implemented a 15-minute handoff meeting with a checklist template. Six months later: zero dropped incidents and faster ramp-up for new team members.
The meeting is not a status call. It has one job: confirm that the incoming engineer's mental model matches the outgoing engineer's. Have the incoming engineer summarize back before the outgoing engineer signs off. If the summary is wrong or incomplete, that's the gap the handoff message missed.
Target 15 to 30 minutes - enough to cover the checklist without being a burden. For a week with no incidents, 10 minutes is enough. The structured Slack message doubles as the meeting agenda, which means the meeting needs no separate preparation.
The practical sequence that works:
- Outgoing engineer drafts the five-field Slack message before the meeting (or an AI teammate drafts it from existing context for review)
- Post it to the handoff channel so the incoming engineer can read it cold
- Run the 15-minute verbal sync; incoming engineer summarizes back what they're inheriting
- Outgoing engineer corrects anything missing; both engineers reply with a thread ack
- Incoming engineer pins the message in the channel for the week
Make it visible where the work happens. Put the current handoff in Slack: channel topic, pinned message, and a daily post if the shift is active.
On-call handoff in Slack: common questions
What should an on-call handoff Slack message include?
Five fields: active issues with status and next step, silenced alerts with expiry and reason, a watchlist of degraded-but-not-alerting services, upcoming risk events like deploys or cert expiries, and named escalation contacts. Post the five fields in the main message; put full timelines and dashboard links in the thread. Keep the whole message under 300 words.
How long should an on-call handoff take?
Target 15 minutes for the verbal sync after the written message is posted. The message does the heavy lifting; the meeting confirms the incoming engineer's mental model is correct. For a quiet week, 10 minutes is enough. Only extend to 30-45 minutes if there are active, unresolved incidents changing shape.
Why do on-call handoffs fail even when teams have a rotation tool?
A rotation tool tells you who owns the shift. It does not transfer operational context about what's silenced, what's degraded, or what the outgoing engineer would watch if they stayed. That context lives in the outgoing engineer's head - and without a structured prompt to extract it, it stays there. The rotation schedule and the handoff message are two separate things.
Can AI draft the on-call handoff message automatically?
Yes, with some structure. An AI teammate connected to your incident channel, Linear or Jira, and your deploy log can pre-populate most of the five fields - active tickets, recent deploys, threads that mention alert suppression. The outgoing engineer still needs to review and add anything not yet in a written source, like the intuition-level watchlist items. Draft-and-approve keeps the context accurate and the send fast.