On-Call Handoff Template

Overview

Poor on-call handoffs are a leading cause of incident escalation. When context is lost between shifts, the incoming engineer wastes precious minutes re-discovering what the outgoing engineer already knew. This template standardizes the handoff process, ensuring critical information about active incidents, ongoing alerts, and system state is transferred completely and consistently.

When to Use

• For alternatives, see Incident Communication Template.

Use this template when:

• Transferring on-call responsibility between shifts or team members
• Going on vacation or extended leave with on-call coverage
• Handing off during a prolonged incident that spans multiple shifts
• Rotating on-call responsibilities weekly or bi-weekly

Prerequisites

Before the handoff:

• Outgoing engineer reviews all active alerts and incidents
• Runbooks for ongoing issues are updated with latest findings
• Incident channel history is summarized for context
• Upcoming scheduled changes or deployments are noted

Solution

# On-Call Handoff Report

## Handoff Metadata

| Field | Value |
|-------|-------|
| Outgoing engineer | ______ |
| Incoming engineer | ______ |
| Handoff date/time | ______ |
| Shift duration | ______ |

## 1. Active Incidents

### Incident #1: `<Title>`
| Field | Value |
|-------|-------|
| Status | Investigating / Mitigated / Resolved |
| Severity | P1 / P2 / P3 / P4 |
| Start time | ______ |
| Incident channel | ______ |
| Current owner | ______ |

**Summary:**
One-paragraph description of what happened, what has been tried, and current state.

**Next steps:**
- [ ] Action item 1 (owner: ______, deadline: ______)
- [ ] Action item 2 (owner: ______, deadline: ______)

**Runbook / Reference:**
Link to relevant runbook or troubleshooting guide.

---

### Incident #2: `<Title>`
(Same structure as above)

## 2. Ongoing Alerts & Warnings

| Alert | Status | First Seen | Notes |
|-------|--------|------------|-------|
| High latency on API | WARN | 2 hours ago | Correlates with traffic spike, not useful yet |
| Disk usage > 80% | WARN | 1 day ago | Cleanup scheduled for tonight |
| Replication lag > 5s | OK | Just resolved | Auto-resolved after index rebuild |

## 3. System Health Summary

| Component | Status | Notes |
|-----------|--------|-------|
| API latency p95 | Healthy / Degraded / Critical | Current value: ______ |
| Error rate | Healthy / Degraded / Critical | Current value: ______ |
| Database connections | Healthy / Degraded / Critical | Current value: ______ |
| Queue depth | Healthy / Degraded / Critical | Current value: ______ |
| Cache hit rate | Healthy / Degraded / Critical | Current value: ______ |
| Disk usage | Healthy / Degraded / Critical | Current value: ______ |

## 4. Changes & Deployments

### Completed This Shift
| Change | Time | Status | Impact |
|--------|------|--------|--------|
| Database index rebuild | 02:00 UTC | Success | Reduced query time by 40% |
| Config update for caching | 14:30 UTC | Success | No impact observed |

### Scheduled Next Shift
| Change | Time | Risk | Prepared? |
|--------|------|------|-----------|
| Kubernetes upgrade | 06:00 UTC | Medium | Rollback tested, on-call aware |
| SSL certificate renewal | 10:00 UTC | Low | Auto-renewal configured |

## 5. Known Issues & Workarounds

| Issue | Workaround | Ticket | Priority |
|-------|------------|--------|----------|
| Memory leak in worker process | Restart every 6 hours | INC-123 | Medium |
| Flaky test in CI pipeline | Retry failed job | DEV-456 | Low |

## 6. Escalation Paths

| Scenario | Escalate To | Contact |
|----------|-------------|---------|
| P1 incident > 30 min | Engineering Manager | Slack / Phone |
| Security incident | Security Team | PagerDuty |
| Infrastructure outage | Platform Team | Slack / Phone |
| Data integrity issue | DBA on-call | PagerDuty |

## 7. Notes & Context

**Unusual observations this shift:**
- Any anomalies that don't rise to alert level but could be precursors to issues

**Requests from other teams:**
- Any non-urgent asks that came in during the shift

**General reminders:**
- Any team-specific context the incoming engineer should know

Explanation

The template structures the handoff into incidents (what’s broken), alerts (what might break), health (current state), and changes (what’s coming). The escalation path section is critical for the incoming engineer who may not know who to call at 3 AM. The notes section captures the subtle context that doesn’t fit into other categories but can prevent surprises.

Handoff Checklist

=== Pre-Handoff Checklist ===

[ ] All active incidents documented with current status and next steps
[ ] All alerts from this shift reviewed and disposition noted
[ ] System health dashboard screenshot or link included
[ ] Scheduled changes for next shift documented
[ ] Known issues and workarounds updated
[ ] Escalation paths verified (contacts still valid)
[ ] Unusual observations noted even if not alerting
[ ] Requests from other teams documented
[ ] PagerDuty schedule confirmed for incoming engineer
[ ] Incoming engineer has acknowledged receipt of handoff

=== Handoff Conversation Flow ===

1. Walk through active incidents first (5 min)
2. Review alerts that may escalate (3 min)
3. Check system health together (2 min)
4. Discuss scheduled changes (2 min)
5. Review known issues (2 min)
6. Share unusual observations (1 min)
7. Incoming engineer asks questions (5 min)
8. Both confirm handoff is complete

Variants

Context	Approach	Notes
Daily shift handoff	Abbreviated version (15 min)	Focus on active incidents and alerts only
Weekly rotation	Full template with retrospective	Include incident count, MTTR trends
Vacation coverage	Extended version	Add project context, meeting schedules, stakeholder contacts
Incident mid-handoff	Incident-focused	Focus on the active incident, de-prioritize routine items

What works

1. Conduct handoffs synchronously — async handoffs miss questions and nuance
2. Update the template in real-time — don’t reconstruct it from memory at shift end
3. Link, don’t describe — paste links to dashboards, not screenshots of metrics
4. Include the “so what” — explain why an alert matters, not just that it exists
5. Verify incoming engineer acknowledgment — confirm they have access and understand context

Common Mistakes

1. Only covering active incidents — misses brewing issues that will become incidents
2. Copy-pasting alert descriptions — provides no context about what has been investigated
3. Not mentioning scheduled changes — incoming engineer is surprised by maintenance windows
4. Skipping the escalation path — wastes minutes finding who to call during a P1
5. Handing off during an active incident — context transfer while debugging is lossy; pause the investigation for 5 minutes to document

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Further Reading

• Official documentation: check the current reference for the framework or tool used.
• Related guides: explore the on-call and runbook guides for deeper coverage.
• Complementary patterns: review design patterns applicable to your technology stack.
• Public postmortems: study real incidents from teams that faced similar production issues.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply on-call handoff template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.