Master on-call shift handoffs with context transfer, escalation procedures, and documentation. Use when transitioning on-call responsibilities, documenting shift summaries, or improving on-call processes.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Master on-call shift handoffs with context transfer, escalation procedures, and documentation. Use when transitioning on-call responsibilities, documenting shift summaries, or improving on-call processes.
version
1.1.0
model
sonnet
invoked_by
both
user_invocable
true
tools
["Read","Write","Bash"]
best_practices
["Document everything during shift","Escalate early when uncertain","Keep handoffs synchronous","Test setup before incidents"]
error_handling
graceful
streaming
supported
verified
true
lastVerifiedAt
"2026-02-22T00:00:00.000Z"
source
builtin
trust_score
100
provenance_sha
249c6f14e8962135
Mode: Cognitive/Prompt-Driven — No standalone utility script; use via agent context.
On-Call Handoff Patterns
Effective patterns for on-call shift transitions, ensuring continuity, context transfer, and reliable incident response across shifts.
When to Use This Skill
Transitioning on-call responsibilities
Writing shift handoff summaries
Documenting ongoing investigations
Establishing on-call rotation procedures
Improving handoff quality
Onboarding new on-call engineers
Core Concepts
1. Handoff Components
Component
Purpose
Active Incidents
What's currently broken
Ongoing Investigations
Issues being debugged
Recent Changes
Deployments, configs
Known Issues
Workarounds in place
Upcoming Events
Maintenance, releases
2. Handoff Timing
Recommended: 30 min overlap between shifts
Outgoing:
├── 15 min: Write handoff document
└── 15 min: Sync call with incoming
Incoming:
├── 15 min: Review handoff document
├── 15 min: Sync call with outgoing
└── 5 min: Verify alerting setup
Templates
Template 1: Shift Handoff Document
# On-Call Handoff: Platform Team**Outgoing**: @alice (2024-01-15 to 2024-01-22)
**Incoming**: @bob (2024-01-22 to 2024-01-29)
**Handoff Time**: 2024-01-22 09:00 UTC
---
## Active Incidents### None currently active
No active incidents at handoff time.
---
## Ongoing Investigations### 1. Intermittent API Timeouts (ENG-1234)**Status**: Investigating
**Started**: 2024-01-20
**Impact**: ~0.1% of requests timing out
**Context**:
- Timeouts correlate with database backup window (02:00-03:00 UTC)
- Suspect backup process causing lock contention
Added extra logging in PR #567 (deployed 01/21)
:
[ ] Review new logs after tonight's backup
[ ] Consider moving backup window if confirmed
:
Dashboard: []()
Thread: #platform-eng (01/20, 14:32)
---
: Monitoring
: 2024-01-18
: None yet (proactive)
:
Memory usage growing ~5% per day
No memory leak found in profiling
Suspect connection pool not releasing properly
:
[ ] Review heap dump from 01/21
[ ] Consider restart if usage > 80%
:
Dashboard: []()
Analysis doc: []()
---
: 23 minutes
: Database connection exhaustion
: Rolled back v2.3.4, increased pool size
: []()
: ENG-1230, ENG-1231
---
| Service | Version | Time | Notes |
| ------------ | ------- | ----------- | -------------------------- |
| api-gateway | v3.2.1 | 01/21 14:00 | Bug fix for header parsing |
| user-service | v2.8.0 | 01/20 10:00 | New profile features |
| auth-service | v4.1.2 | 01/19 16:00 | Security patch |
01/21: Increased API rate limit from 1000 to 1500 RPS
01/20: Updated database connection pool max from 50 to 75
01/20: Added 2 nodes to Kubernetes cluster
01/19: Upgraded Redis from 6.2 to 7.0
---
: Grafana dashboards slow on Monday mornings
: Wait 5 min after 08:00 UTC for cache warm-up
: OPS-456 (P3)
: fails intermittently in CI
: Re-run failed job (usually passes on retry)
: ENG-1200 (P2)
---
| Date | Event | Impact | Contact |
| ----------- | -------------------- | ------------------- | ------------- |
| 01/23 02:00 | Database maintenance | 5 min read-only | @dba-team |
| 01/24 14:00 | Major release v5.0 | Monitor closely | @release-team |
| 01/25 | Marketing campaign | 2x traffic expected | @platform |
---
| Issue Type | First Escalation | Second Escalation |
| --------------- | -------------------- | ----------------- |
| Payment issues | @payments-oncall | @payments-manager |
| Auth issues | @auth-oncall | @security-team |
| Database issues | @dba-team | @infra-manager |
| Unknown/severe | @engineering-manager | @vp-engineering |
---
-
**Next Steps**
-
-
**Resources**
-
API Latency
https://grafana/d/api-latency
-
### 2. Memory Growth in Auth Service (ENG-1235)
**Status**
**Started**
**Impact**
**Context**
-
-
-
**Next Steps**
-
-
**Resources**
-
Auth Service Memory
https://grafana/d/auth-memory
-
Memory Investigation
https://docs/eng-1235
## Resolved This Shift
### Payment Service Outage (2024-01-19)
-
**Duration**
-
**Root Cause**
-
**Resolution**
-
**Postmortem**
POSTMORTEM-89
https://docs/postmortem-89
-
**Follow-up tickets**
## Recent Changes
### Deployments
### Configuration Changes
-
-
### Infrastructure
-
-
## Known Issues & Workarounds
### 1. Slow Dashboard Loading
**Issue**
**Workaround**
**Ticket**
### 2. Flaky Integration Test
**Issue**
`test_payment_flow`
**Workaround**
**Ticket**
## Upcoming Events
## Escalation Reminders
## Quick Reference
### Common Commands
```bash
# 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
```
### Template 2: Quick Handoff (Async)
```markdown
# Quick Handoff: @alice → @bob
## TL;DR
- No active incidents
- 1 investigation ongoing (API timeouts, see ENG-1234)
- Major release tomorrow (01/24) - be ready for issues
## Watch List
1. API latency around 02:00-03:00 UTC (backup window)
2. Auth service memory (restart if > 80%)
## Recent
- Deployed api-gateway v3.2.1 yesterday (stable)
- Increased rate limits to 1500 RPS
## Coming Up
- 01/23 02:00 - DB maintenance (5 min read-only)
- 01/24 14:00 - v5.0 release
## Questions?
I'll be available on Slack until 17:00 today.
Template 3: Incident Handoff (Mid-Incident)
# INCIDENT HANDOFF: Payment Service Degradation**Incident Start**: 2024-01-22 08:15 UTC
**Current Status**: Mitigating
**Severity**: SEV2
---
## Current State- Error rate: 15% (down from 40%)
- Mitigation in progress: scaling up pods
- ETA to resolution: ~30 min
## What We Know1. Root cause: Memory pressure on payment-service pods
2. Triggered by: Unusual traffic spike (3x normal)
3. Contributing: Inefficient query in checkout flow
## What We've Done- Scaled payment-service from 5 → 15 pods
- Enabled rate limiting on checkout endpoint
- Disabled non-critical features
## What Needs to Happen1. Monitor error rate - should reach <1% in ~15 min
2. If not improving, escalate to @payments-manager
3. Once stable, begin root cause investigation
## Key People- Incident Commander: @alice (handing off)
- Comms Lead: @charlie
- Technical Lead: @bob (incoming)
## Communication- Status page: Updated at 08:45
- Customer support: Notified
- Exec team: Aware
## Resources- Incident channel: #inc-20240122-payment
- Dashboard: [Payment Service](https://grafana/d/payments)
- Runbook: [Payment Degradation](https://wiki/runbooks/payments)
---
**Incoming on-call (@bob) - Please confirm you have:**- [ ] Joined #inc-20240122-payment
- [ ] Access to dashboards
- [ ] Understand current state
- [ ] Know escalation path
Handoff Sync Meeting
Agenda (15 minutes)
## Handoff Sync: @alice → @bob1.**Active Issues** (5 min)
- Walk through any ongoing incidents
- Discuss investigation status
- Transfer context and theories
2.**Recent Changes** (3 min)
- Deployments to watch
- Config changes
- Known regressions
3.**Upcoming Events** (3 min)
- Maintenance windows
- Expected traffic changes
- Releases planned
4.**Questions** (4 min)
- Clarify anything unclear
- Confirm access and alerting
- Exchange contact info
On-Call Best Practices
Before Your Shift
## Pre-Shift Checklist### Access Verification- [ ] VPN working
- [ ] kubectl access to all clusters
- [ ] Database read access
- [ ] Log aggregator access (Splunk/Datadog)
- [ ] PagerDuty app installed and logged in
### Alerting Setup- [ ] PagerDuty schedule shows you as primary
- [ ] Phone notifications enabled
- [ ] Slack notifications for incident channels
- [ ] Test alert received and acknowledged
### Knowledge Refresh- [ ] Review recent incidents (past 2 weeks)
- [ ] Check service changelog
- [ ] Skim critical runbooks
- [ ] Know escalation contacts
### Environment Ready- [ ] Laptop charged and accessible
- [ ] Phone charged
- [ ] Quiet space available for calls
- [ ] Secondary contact identified (if traveling)
During Your Shift
## Daily On-Call Routine### Morning (start of day)- [ ] Check overnight alerts
- [ ] Review dashboards for anomalies
- [ ] Check for any P0/P1 tickets created
- [ ] Skim incident channels for context
### Throughout Day- [ ] Respond to alerts within SLA
- [ ] Document investigation progress
- [ ] Update team on significant issues
- [ ] Triage incoming pages
### End of Day- [ ] Hand off any active issues
- [ ] Update investigation docs
- [ ] Note anything for next shift
After Your Shift
## Post-Shift Checklist- [ ] Complete handoff document
- [ ] Sync with incoming on-call
- [ ] Verify PagerDuty routing changed
- [ ] Close/update investigation tickets
- [ ] File postmortems for any incidents
- [ ] Take time off if shift was stressful
Escalation Guidelines
When to Escalate
## Escalation Triggers### Immediate Escalation- SEV1 incident declared
- Data breach suspected
- Unable to diagnose within 30 min
- Customer or legal escalation received
### Consider Escalation- Issue spans multiple teams
- Requires expertise you don't have
- Business impact exceeds threshold
- You're uncertain about next steps
### How to Escalate1. Page the appropriate escalation path
2. Provide brief context in Slack
3. Stay engaged until escalation acknowledges
4. Hand off cleanly, don't just disappear
Best Practices
Do's
Document everything - Future you will thank you
Escalate early - Better safe than sorry
Take breaks - Alert fatigue is real
Keep handoffs synchronous - Async loses context
Test your setup - Before incidents, not during
Don'ts
Don't skip handoffs - Context loss causes incidents
ALWAYS write a handoff document before ending a shift — sync calls alone are insufficient; spoken context is forgotten within hours; the document is the durable record the incoming engineer can return to at 3am.
NEVER skip the sync call for on-call handoffs — async-only handoffs lose nuance, tone, and the ability to answer questions; 15 minutes of overlap prevents hours of confusion for the incoming engineer.
ALWAYS escalate within 30 minutes of being stuck on an incident — spending hours debugging alone delays resolution and exhausts the on-call engineer; escalation is a sign of good judgment, not weakness.
NEVER skip verification of alerting setup before a shift begins — discovering a misconfigured PagerDuty routing during an active incident is too late; test the full alert path before every shift.
ALWAYS document every open investigation with explicit next steps — handing off without next steps forces the incoming engineer to restart from zero; written action items reduce handoff ramp-up from hours to minutes.
Anti-Patterns
Anti-Pattern
Why It Fails
Correct Approach
Async-only handoff (no sync call)
Context loss causes incidents; nuance lost; questions go unanswered
Always do a sync call (minimum 15 min overlap) plus a written document
No handoff document
New on-call engineer blind to ongoing issues; 3am ramp-up impossible
Write full handoff document before ending every shift
Skipping alerting verification before shift
Misconfigured routing discovered during incident — too late to fix
Test PagerDuty routing and Slack notifications before every shift starts
Hero culture (not escalating)
Individual burnout; delayed resolution; poor decisions under fatigue
Escalate within 30 minutes of being stuck; escalation is good judgment
Handing off investigations without next steps
Incoming engineer must restart investigation from scratch
Document current state, theories, evidence, and explicit next steps for every open item
Memory Protocol (MANDATORY)
Before starting:
Read .claude/context/memory/learnings.md
After completing:
New pattern -> .claude/context/memory/learnings.md
Issue found -> .claude/context/memory/issues.md
Decision made -> .claude/context/memory/decisions.md
ASSUME INTERRUPTION: If it's not in memory, it didn't happen.
