| name | on-call-handoff-checklist |
| enabled | true |
| description | Use when performing on call handoff checklist — structured on-call rotation
handoff checklist ensuring effective context transfer between outgoing and
incoming on-call engineers. Covers active incidents, known issues, recent
deployments, pending alerts, escalation contacts, and environment health
summary to minimize knowledge gaps during rotation transitions.
|
| required_connections | [{"prefix":"slack","label":"Slack (for handoff notes)"}] |
| config_fields | [{"key":"outgoing_engineer","label":"Outgoing On-Call Engineer","required":true,"placeholder":"e.g., Alice Johnson"},{"key":"incoming_engineer","label":"Incoming On-Call Engineer","required":true,"placeholder":"e.g., Bob Smith"},{"key":"rotation_name","label":"Rotation/Team Name","required":false,"placeholder":"e.g., Platform Team Primary"}] |
| features | ["INCIDENT"] |
On-Call Handoff Checklist
Rotation: {{ rotation_name }}
Outgoing: {{ outgoing_engineer }} | Incoming: {{ incoming_engineer }}
Pre-Handoff Preparation (Outgoing Engineer)
Complete these items before the handoff meeting:
Handoff Meeting Agenda (15-30 min)
1. Active Incidents and Open Issues
| Issue | Status | Severity | Notes | Tracking |
|---|
| fill in | open/monitoring | SEV level | context | ticket link |
2. Recently Resolved Incidents
| Issue | Resolved | Root Cause | Follow-up Needed |
|---|
| fill in | date/time | brief description | yes/no + details |
3. Recent Deployments and Changes
| Change | When | Service | Risk Level | Rollback Plan |
|---|
| fill in | date/time | service | low/med/high | how to rollback |
4. Known Flaky Alerts
| Alert | Frequency | Action | Notes |
|---|
| fill in | how often | acknowledge/investigate/ignore | context |
5. Upcoming Maintenance Windows
| Window | When | Impact | Owner |
|---|
| fill in | date/time | expected impact | who is driving |
6. Environment Health Summary
- Production: healthy / degraded / issues
- Staging: healthy / degraded / issues
- Key metrics: any concerning trends
- Capacity: any resources approaching limits
7. Escalation Contacts
| Situation | Contact | Method |
|---|
| Database issues | name | phone/slack |
| Network/infra | name | phone/slack |
| Security | name | phone/slack |
| Management escalation | name | phone/slack |
| Vendor support | vendor | support portal/phone |
Incoming Engineer Verification
Post-Handoff Actions
Outgoing Engineer
Incoming Engineer
On-Call Health Metrics to Share
- Total pages received during rotation: ___
- After-hours pages: ___
- False positive alerts: ___
- Average time to acknowledge: ___
- Incidents that required escalation: ___
- Sleep interruptions: ___
These metrics help the team identify on-call burden and improve alert quality over time.
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
