Standardize On-Call Handoffs

This skill covers patterns for on-call shift transitions, ensuring continuity, context transfer, and reliable incident response across shifts. It defines five handoff components to always cover - active incidents, ongoing investigations, recent changes (deployments, configs), known issues/workarounds, and upcoming events (maintenance, releases) - and recommends a 30-minute overlap between shifts: 15 minutes for the outgoing engineer to write the handoff document, then a 15-minute sync call, followed by the incoming engineer reviewing the document, joining the sync call, and spending 5 minutes verifying alerting setup. It provides three handoff templates: a full Shift Handoff Document (outgoing/incoming names and dates, active incidents, ongoing investigations with status/context/next-steps/resources, resolved-this-shift items with postmortem links, a recent-deployments table, configuration and infrastructure changes, known issues with workarounds and tickets, an upcoming-events table, an escalation-reminders table by issue type, a quick-reference command block, and separate outgoing/incoming checklists); a Quick Handoff (Async) template condensing the same into a TL;DR, watch list, recent changes, and upcoming items; and an Incident Handoff template for handing off mid-incident (current state, what's known, what's been done, what needs to happen, key people including incident commander/comms lead/technical lead, communication status, resources, and an incoming-on-call confirmation checklist). It gives a 15-minute Handoff Sync Meeting agenda (5 min active issues, 3 min recent changes, 3 min upcoming events, 4 min questions), and pre-shift/during-shift/post-shift checklists covering access verification, alerting setup, knowledge refresh, environment readiness, daily routine, and postmortem filing. It lists escalation triggers (SEV1 declared, suspected data breach, unable to diagnose within 30 minutes, customer or legal escalation) versus considerations (cross-team issues, missing expertise, high business impact, uncertainty) and a four-step how-to-escalate procedure. Its Do's/Don'ts list: document everything, escalate early, take breaks, keep handoffs synchronous, and test your setup beforehand - versus skipping handoffs, heroing instead of escalating, ignoring minor alerts, working sick, or going unreachable during a shift.

Use it when transitioning on-call responsibilities, writing shift handoff summaries, documenting ongoing investigations, establishing on-call rotation procedures, improving handoff quality, or onboarding new on-call engineers. It does not apply outside on-call handoff patterns - a different domain or tool is out of scope.

Inputs: the state of active incidents, ongoing investigations, recent deployments/config changes, known issues, and upcoming events at shift-change time. Outputs: a completed handoff document (full, async, or mid-incident variant) matched to the situation, a synced outgoing/incoming engineer pair, and a verified alerting/access setup for the incoming on-call.

PagerDuty for on-call scheduling and alert routing, Slack for incident channels and async handoffs, Grafana for dashboards referenced from handoff documents, and Kubernetes/PostgreSQL/Redis for the example quick-reference commands.

# Check service health
kubectl get pods -A | grep -v Running

# Recent deployments
kubectl get events --sort-by='.lastTimestamp' | tail -20

# Database connections
psql -c "SELECT count(*) FROM pg_stat_activity;"

# Clear cache (emergency only)
redis-cli FLUSHDB

On-call engineers and team leads who need a structured, synchronous handoff instead of ad hoc, context-losing shift transitions.