Free On-Call Handoff Template (Copy-Paste)

Overview

An on-call handoff (also written “handover”) is the structured transfer of operational context and responsibility from the outgoing engineer to the incoming one at shift change. Poor handoffs are a leading cause of incident escalation: when context is lost, the incoming engineer burns precious minutes re-discovering what the outgoing engineer already knew.

This template standardizes the handoff so critical information about active incidents, ongoing alerts, and system state transfers completely every time. Below you get the blank template, a filled-in example, a Slack-ready short format, and the checklist to run the actual conversation. Copy it into your team wiki and adapt the sections to your stack — the structure survives customization better than any specific field list.

When to Use

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 duties weekly or bi-weekly

It’s overkill for a team of one (you’re just talking to yourself) and unnecessary when the incoming engineer already sat in the incident channel all shift. For communicating with stakeholders rather than the next engineer, use the Incident Communication Template instead: different audience, different detail.

Before the Handoff

Ten minutes before the conversation:

• 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
• The handoff document is already filled in; don’t write it during the call from memory

The last point matters more than the rest. Memory compresses badly under fatigue, and end-of-shift is exactly when you’re most tired. Update the document as things happen during the shift, and the pre-handoff review becomes a ten-minute sanity check instead of an hour of reconstruction.

The Template

# 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 |
|-------|--------|------------|-------|
| ______ | WARN / OK | ______ | ______ |

## 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 |
|--------|------|--------|--------|
| ______ | ______ | ______ | ______ |

### Scheduled Next Shift
| Change | Time | Risk | Prepared? |
|--------|------|------|-----------|
| ______ | ______ | ______ | ______ |

## 5. Known Issues & Workarounds

| Issue | Workaround | Ticket | Priority |
|-------|------------|--------|----------|
| ______ | ______ | ______ | ______ |

## 6. Escalation Paths

| Scenario | Escalate To | Contact |
|----------|-------------|---------|
| ______ | ______ | ______ |

## 7. Access & Environment Check

- [ ] Incoming engineer is on the PagerDuty/Opsgenie rotation
- [ ] VPN and production access verified this week
- [ ] Dashboards, log viewers, and deploy tools reachable
- [ ] Incident Slack channels joined and unmuted
- [ ] Physical location / timezone noted for the shift

## 8. 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

The eight sections map to the questions the incoming engineer will actually ask, in roughly the order they’ll ask them. Incidents first because that’s what’s on fire; alerts next because those become incidents; health and changes to establish what’s normal and what’s about to shift; known issues and escalation paths so nothing is discovered cold at 3 AM; access verification because it’s the cheapest check to run and the most embarrassing to skip; and notes for everything that doesn’t fit a table but still matters.

The filled version below shows what “good” looks like: a real handoff compresses into something scannable in two minutes.

Filled Example

## 1. Active Incidents

### Incident #1: Payment API 500s after deploy
| Field | Value |
|-------|-------|
| Status | Mitigated (rollback done, monitoring) |
| Severity | P2 |
| Start time | 14:35 UTC |
| Incident channel | #inc-payment-500s |
| Current owner | Dana (incoming takes over) |

**Summary:**
Checkout errors spiked to 12% after deploy 4f2a1c. Rolled back at
15:20, error rate back to baseline (0.3%). Root cause suspected:
missing DB index on new query path. Index is building now.

**Next steps:**
- [ ] Verify index build finished (ETA ~18:00 UTC, owner: Dana)
- [ ] Post incident summary in channel before EOD (owner: Dana)

## 2. Ongoing Alerts & Warnings

| Alert | Status | First Seen | Notes |
|-------|--------|------------|-------|
| High latency on API | WARN | 2h ago | Correlates with the deploy, watch it |
| Disk usage > 80% | WARN | 1d ago | Cleanup cron runs tonight at 02:00 |

## 7. Access & Environment Check

- [x] Dana confirmed on PagerDuty rotation for this week
- [x] Dashboards and deploy tools verified last Tuesday
- [ ] #inc-payment-500s joined — needs invite, sending now

Notice the example mixes resolved-ish work (the mitigated incident) with things that will bite later (the disk alert, the unjoined channel). That’s the point of the handoff: the boring details are what people forget at 3 AM.

Slack / Async Variant

When there’s no overlap window (different time zones, on-call coverage gaps), a structured Slack message beats a wiki page nobody opens. Keep it under 15 lines or people stop reading:

HANDOFF @channel — out 18:00 UTC, Dana takes over until 08:00

INCIDENT: Payment API 500s — P2, mitigated via rollback 15:20.
Channel: #inc-payment-500s. Next: confirm index build ~18:00.

WATCH: API latency alert still WARN (2h), disk >80% cleanup at 02:00.

CHANGES: k8s upgrade 06:00 UTC tomorrow — rollback tested.

NOTES: Support ticket #4521 (billing delay) is related noise, not a bug.

Ack with 👍 when you've read it. Ping me if anything's unclear tonight.

Async handoffs work for routine rotations. For an active P1, insist on a synchronous handoff; questions you can’t answer in a chat thread are the ones that matter. If your team uses a ticket-centric flow instead, the same sections map cleanly onto a Jira or Linear issue; see the On-Call Runbook Template for the broader runbook structure this fits into.

Sync vs Async Handoffs

Synchronous handoffs catch what documents miss. The incoming engineer hears hesitation in your voice when you describe an alert you’re not sure about, and they can interrupt with “wait, does that correlate with the deploy?” in a way that never happens over text. Default to sync whenever the overlap exists.

Async is the fallback for time-zone gaps and it only works with two rules: a written document that’s complete enough to stand alone (the Slack variant above, or the full template pasted somewhere persistent), and an explicit acknowledgment deadline. “Ack within 30 minutes” catches the failure mode where nobody noticed the handoff happened at all. For anything ambiguous, a recorded video walkthrough (Loom or similar) recovers some of the sync benefit: the outgoing engineer narrating the dashboard is worth more than the same text twice.

Explanation

The template structures the handoff into incidents (what’s broken), alerts (what might break), health (current state), and changes (what’s coming). Two sections earn their place specifically:

• Escalation paths exist for the incoming engineer who doesn’t know who to call at 3 AM. Without it, the first P1 of the shift starts with fifteen minutes of “who do I page?”
• Access & environment check sounds trivial until the new person discovers at 02:00 that their VPN cert expired or they can’t see the deploy pipeline. Verify access during the handoff, while the outgoing engineer can still fix it.

“Handoff” and “handover” mean the same thing here: the former is common in US teams, the latter in UK/international ones. Use whichever your org does; just keep it consistent in documents so search finds them.

Measuring Handoff Quality

A handoff process you never measure quietly degrades into a ritual nobody reads. Review handoff documents weekly in the team meeting: highlight good ones, call out gaps, and keep it brief. Three metrics tell you whether it’s working:

• Incidents missed after handoff: how often the incoming engineer gets surprised by something the outgoing engineer knew. This should trend to zero.
• Time to first response after shift change: if the new on-call takes noticeably longer to ack the first alert, context transfer is failing.
• Incoming engineer confidence: a monthly one-question survey: “Did the handoff give you enough context to handle the shift?” Cheap to run, brutally honest.

Use the answers to prune the template. Sections that come back empty week after week are either unnecessary or unclear; either way, fix or delete them. Sections that keep producing “I didn’t know that” moments deserve to stay. And when several teams run on-call in the same org, compare notes once a quarter — the best handoff conventions I’ve seen were stolen from another team’s document, not invented.

Keeping the Template Useful

Put the document somewhere people actually look during an incident. A shared doc per shift, a running thread in the on-call Slack channel, or a page in the incident management tool all work; a file on someone’s laptop does not. Whatever you pick must be searchable. Handoffs become useful history when debugging a recurring issue weeks later — “didn’t we see this exact latency pattern last month?” is only answerable if the old handoffs still exist.

Treat the template itself like code: keep it under version control or in the team wiki, review it quarterly, and make the newest engineer on the rotation the reviewer. Fresh eyes spot the sections that stopped making sense two reorganizations ago.

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 link included (not a screenshot)
[ ] Scheduled changes for next shift documented
[ ] Known issues and workarounds updated
[ ] Escalation paths verified (contacts still valid)
[ ] Incoming engineer's access confirmed (see template section 7)
[ ] Unusual observations noted even if not alerting
[ ] Requests from other teams documented
[ ] Incoming engineer has acknowledged receipt of handoff

A synchronous handoff conversation runs about twenty minutes:

Handoff During an Active Incident

The hardest case is a rotation change in the middle of a P1 or P2. Both engineers are tired, context is split between five tools, and the temptation is to skip the handoff entirely — which is how incidents stall for an hour while the new engineer catches up.

Do a focused micro-handoff instead: pause the incident for five minutes, run only sections 1, 6, and 7 of the template (the active incident, escalation contacts, access check), and state explicitly who now owns the incident. Skip the routine items; a disk alert can wait when payments are down. Write the micro-handoff in the incident channel itself, where it also serves as a timeline entry for the postmortem. If the outgoing engineer is deep in a debugging session, keep them as a named secondary for the first hour rather than losing their context mid-hypothesis.

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
Async / time-zone gap	Slack variant above	Written document + ack deadline, no live call

What Works

1. Run handoffs synchronously when possible. Async misses the questions that matter.
2. Update the document during the shift, not at the end from memory.
3. Link, don’t describe. Paste dashboard URLs, not screenshots of metrics.
4. Write the “so what” for every alert: why it matters, not just that it fired.
5. Get explicit acknowledgment. “Read it” isn’t a confirmation; “I have access and context” is.

Common Mistakes

1. Covering only active incidents: brewing issues become tomorrow’s P1s.
2. Copy-pasting alert text verbatim: useless without what you already investigated.
3. Forgetting scheduled changes: the incoming engineer gets surprised by maintenance windows.
4. Skipping escalation paths: wastes minutes finding who to call during a P1.
5. Handing off mid-incident without pausing: pause five minutes to document, or context gets lost in the debugging noise.
6. Assuming access works: the classic failure is an incoming engineer who can’t log in to anything.

After the Handoff

The incoming engineer’s job isn’t done at “confirmed.” Within the first hour: actually open the dashboards and tools (don’t take the access check on faith), skim the incident channels referenced in the document, and set reminders for scheduled changes so the 06:00 upgrade isn’t a surprise at 06:05.

The outgoing engineer isn’t fully done either. Stay reachable for the first hour in case the mental model you transferred has gaps, and file anything you explained verbally that wasn’t already in the runbook; if you had to say it out loud, it belongs in writing.

• Google SRE Book — Being On-Call: the canonical chapter on on-call duties and handoff discipline.
• PagerDuty — Incident Response Guide: roles, severities, and escalation conventions these templates assume.
• Atlassian — Incident Management Handbook: broader process context for incident workflows.
• NIST SP 800-61 — Incident Handling Guide: formal reference for incident phases if your org needs compliance alignment.

Companion files: the blank template and filled example live in the companion repo — copy them straight into your wiki.