SkillMedev On-Call Handoff
A handoff note transfers your mental model, not just your ticket queue. The incoming engineer should be able to respond to the next alert without asking you anything - because at 3am, "ask the previous on-call" is not an option, and the most expensive handoff failure is the one-line "quiet shift, nothing to report" that omits the silenced alert or the half-finished migration that pages them four hours later.
Operating procedure
Step 1: Gather the shift's raw material
Pull these before writing - memory alone misses exactly the items that matter:
- Paging history for the shift: count and severity of pages.
- Open or partially resolved incident tickets.
- Every alert you silenced, snoozed, or downgraded - from the monitoring system, not memory. A silenced alert with no expiry is a landmine.
- All deploys, config changes, migrations, and infra changes in the last 24 hours - including other teams' changes to shared systems if you know of them.
- Anything in flight: fixes pending review, vendor tickets open, scheduled maintenance windows.
Step 2: Write the note in this fixed order
The order is deliberate: the reader triages the note the same way they triage a page - summary first, active fires second, smoke third.
1. Shift summary (2-3 lines). SEV count by level, total pages received, one-sentence characterization. "Quiet - 2 SEV4 tickets, no pages." or "Rough - 1 SEV2 that took 4 hours to resolve, system is stable now."
2. Open incidents. For each open or partially resolved incident: ticket/incident ID and title; current status and last action taken; what you expect to happen next and by when; who owns it if not on-call. If there are none, say so explicitly: "No open incidents." Silence is ambiguous; the explicit line is not.
3. Watch items (limit 3-5). Things that are not incidents yet but could become one. For each: the signal, why it is concerning, and - critically - the threshold that should trigger paging, plus the dashboard link. Example: "Payment latency at p99 = 820ms, normal is under 400ms. No SLO breach yet. If it crosses 1s for 10 minutes, page the payments team. Link: [dashboard]." A watch item without a numeric threshold delegates a judgment call to someone with less context than you.
4. Silenced and modified alerts. Every alert currently silenced, snoozed, or with a temporarily raised threshold: which alert, why, and when the silence expires or should be lifted. If a silence has no expiry, set one now - before handing off.
5. Recent changes (last 24h). Deploys, config changes, migrations, infra changes. These are the first suspects when the next alert fires. One line each: [Time] [Service] [What changed] [Who made it] [Rollback? Y/N]. The rollback flag matters most - it is the difference between a 5-minute mitigation and a 2-hour investigation.
6. Context and notes. Anything needed that fits nowhere above: vendor communications in progress, scheduled maintenance windows, a known flaky alert, a fix pending review. Bullet points only. If a service involved has unusual architecture, add one sentence of context rather than assuming shared jargon.
7. Escalation contacts (only if non-standard). If a vendor ticket is open or an unusual escalation path is active, list the contact and reference number. Omit the standard rotation - it is in the paging tool.
Step 3: Run the completeness checklist
Do not send until every box is checked:
- Every open incident has a next-expected-action and a time.
- Every watch item has a numeric paging threshold and a dashboard link.
- Every silenced alert is listed with a reason and an expiry.
- Every in-flight change (deploy, migration, pending fix) appears with its rollback status.
- "No open incidents" is stated explicitly if true - no section left blank.
- Every ticket, dashboard, and Slack thread is linked, not pasted in.
Step 4: Deliver before the shift ends
Post the note before your shift ends, not after the next person has started - and offer a 5-minute synchronous overlap if any open incident is active. Written notes carry facts; the overlap carries the hunches.
Worked artifact: filled handoff template
ON-CALL HANDOFF - [FILL: rotation name] - [FILL: date] - [FILL: your name] → [FILL: incoming name]
SHIFT SUMMARY
[FILL: e.g. "Moderate - 1 SEV3 (resolved), 6 pages total, 4 were the flaky
disk alert on db-replica-2."]
OPEN INCIDENTS
[FILL: "INC-4312 - checkout errors for EU users. Mitigated by failing over to
eu-west-2 at 14:20; root cause unknown. Expect networking team update by 09:00.
Owner: networking (Dana), not on-call." - or "No open incidents."]
WATCH ITEMS (max 5, each with a threshold + link)
1. [FILL: "Payment p99 latency at 820ms, normal <400ms. No SLO breach. Page
payments team if >1s for 10 min. Dashboard: <link>"]
SILENCED / MODIFIED ALERTS
[FILL: "disk-usage-warn on db-replica-2 silenced until Tue 10:00 - known noisy
after Friday's compaction change, tracking in OPS-889." - or "None."]
RECENT CHANGES (last 24h)
[FILL: "16:40 | billing-svc | v2.14 deploy (invoice rounding fix) | Marco |
Rollback: Y"]
CONTEXT / NOTES
- [FILL: vendor tickets, maintenance windows, pending fixes, flaky alerts]
NON-STANDARD ESCALATION
[FILL: "AWS support case #8834412001 open re: NAT gateway - respond via the
case, not the TAM." - or "None."]
Deliverable
Produce a posted handoff note in the seven-section order above, with every checklist box passing, delivered before shift end, plus a synchronous overlap offer when any incident is open.
Do NOT
- Do not include solved incidents with no follow-up - past is past unless a watch item remains; resolved-incident storytelling buries the live signals.
- Do not under-communicate a watch item because it will "probably resolve" - if you are watching it, they need to know; the cost of one extra bullet is zero.
- Do not hand off a silenced alert without an expiry - an indefinite silence is how a real outage goes unnoticed.
- Do not copy-paste ticket or dashboard contents - link them; pasted content goes stale the moment the incident moves.
- Do not use team-internal jargon or codenames without one sentence of context - the incoming engineer may be from a sister rotation.
- Do not write the note after your shift ends - the gap between shifts is exactly when an unowned page lands.
Quality bar
A handoff is done when the incoming engineer could handle the next page without contacting you: every live thread has a link, an owner, and an expected next step; every threshold is a number, not an adjective; and the note reads in under three minutes.
Related skills
When a resolved incident needs a write-up, hand it to postmortem-writer - the handoff note is continuity, not analysis. During an active incident, severity and mobilization decisions belong to sev-triage. Recurring noisy alerts surfacing in every handoff are an alert-tuning problem; route them there instead of re-documenting them each shift.