On-Call Handoffs: Phrases for Incident & Shift Handover

Option C is the correct opening. It signals the handoff ('handing off now'), gives an overall status ('stable overall'), and immediately flags the exception ('one open incident on the payment service') with a commitment to walk through it. 'Here's what happened today' (A) sounds like a diary entry rather than a structured handoff. 'Your turn now, good luck' (B) is casual and provides no information. 'Everything should be fine' (D) is dangerously vague — if it's not fine, your successor has no context to act on. A handoff opener should always state overall status and flag any exceptions upfront.

Option A is the precise watch-out. It names the component (cache cluster), describes the pattern (flapping every 3-4 hours), and honestly states the knowledge gap (haven't found the root cause yet). That last part is important — it tells your successor not to spend time looking for a fix that doesn't exist yet. 'There's a problem with the cache sometimes' (B) is vague — how often is 'sometimes'? 'The cache has been a bit unreliable' (C) gives a general impression but no actionable detail. 'Keep an eye on caching' (D) is so vague it provides no guidance. Effective warnings always name frequency, component, and current investigation status.

Option D gives the complete picture: classifies it as known (no need to investigate), names the root cause (index on user_events), provides a specific ETA (14:00 UTC), and points to the source of truth (ticket in the incident channel). 'There's a known bug we haven't fixed' (A) gives no root cause and no ETA. 'This bug has been around a while' (B) gives no information useful for the incoming shift. 'We hope to fix it soon' (C) is vague and slightly unprofessional — 'hope' signals uncertainty without quantifying it. Known issues in handoffs always need: root cause, ETA, and a link to the tracking ticket.

Option B sets precise, measurable escalation criteria: two specific triggers (error rate above 1%, any failed payment), and a clear default for everything else (otherwise hold). 'Just call someone if things go wrong' (A) is subjective — 'things go wrong' means different things to different people. 'You'll know when to escalate' (C) is worse — it assumes intuition that the incoming engineer may not have developed yet. 'Contact the platform team if there are problems' (D) is similarly vague. Escalation criteria should always be binary and measurable, not judgment-based, especially for on-call engineers who are new to the system.

Option A is actionable and specific. It names the runbook by function (cache flush), points to where it lives (the incident doc), and saves time by flagging the critical step (step 3 is the one that matters). 'There's a runbook somewhere' (B) is nearly useless — where is somewhere? 'Check the documentation if something breaks' (C) defers discovery to the moment of crisis, which is the worst time to go hunting for docs. 'We have runbooks for these kinds of issues' (D) confirms they exist but gives no location or guidance. Effective runbook references always: name the runbook, say where it lives, and call out the most important step.