Skip to main content

Operational templates

On-Call Handover Template

A shift handover that transfers state rather than reassurance — what is degraded, what is suppressed, what is scheduled, and what the next person must not be surprised by.

Reviewed 2026-09-21 · next review 2027-09-21

WHEN TO USE IT At every on-call rotation boundary, including within-day handovers across time zones. The value is highest exactly when the outgoing shift was quiet, because that is when handover feels unnecessary and silent state accumulates. HOW TO USE IT The outgoing engineer writes it; the incoming engineer confirms receipt. Ten minutes, synchronous if possible. The single most important line is the suppression list: an alert someone silenced at 3am is invisible to the next person unless it is written down, and a suppressed alert nobody remembers is how an incident runs for a day. Post it where the team can see it, not in a direct message. The transcript is the record. THE TEMPLATE # On-call handover — <date>, <shift> Outgoing: <name> Incoming: <name> ## Currently degraded Anything not fully healthy right now, even if no alert is firing. | What | Since | Impact | Ticket | ## Suppressed or silenced THE MOST IMPORTANT SECTION. Every silence, who set it, when it expires. | Alert | Silenced by | Expires | Why | ## Open incidents Number, severity, current owner, next step, and who to escalate to. ## Recent changes Deploys, config changes, feature flags flipped, migrations run in the last 24 hours — the usual first place to look. ## Scheduled during your shift Maintenance windows, planned deploys, chaos experiments, batch jobs. A surprise experiment is indistinguishable from an incident. ## Known noisy alerts What will page you that is probably fine, and how to tell when it is not. ## Anything you would want to know Free text. This is where the useful thing usually goes. Acknowledged by <incoming> at <time>. ADAPTING IT Teams with mature alerting can drop the noisy-alert section — and should treat needing it as a signal to tune. Teams running follow-the-sun rotations should add an explicit "questions for the previous shift" field, since asynchronous handover loses the chance to ask. Keep it to one screen. A handover document that scrolls does not get read at the start of a shift, which is the only moment it matters. Pair with /runbooks for the procedures and /incidentops for the escalation path.