## TL;DR
A good handoff answers one question: "what do I need to know to not get surprised tonight." Write it the same way every time: active incidents with current state and next action, watch items, in-flight deploys, customer commitments with times, and who to call for what. The template below takes ten minutes and prevents the 3am "nobody told me" page.

## The query

```text
on-call handoff template for support engineers
```

## Use this when

- The on-call shift changes, on any schedule
- On-call transfers mid-incident to a fresh engineer
- On-call changes mid-week for coverage
- You keep getting paged for things the previous shift knew about

## Not for

- Incident response runbooks (those live elsewhere)
- Postmortems or debriefs
- Designing the on-call rotation or compensation
- General team status updates

## Steps

### 1. Write it the same way every time, in the same place

Same template, same channel or doc, every handoff. The value is in the habit: the incoming engineer knows exactly where to look and what "normal" looks like.

Expected output: handoffs live in one known location, in one format.

### 2. Lead with active incidents: state, owner, next action

Every open incident gets one line: what it is, where it stands, who owns it, and what happens next. If there are no active incidents, write "none." Silence is ambiguous; "none" is information.

Expected output: the incoming engineer can recite the incident list from memory.

### 3. List watch items: things that might page tonight

Degraded but stable systems, vendor issues being monitored, deploys still baking, traffic anomalies that didnt trigger alerts. Watch items are the difference between a surprise page and an expected one.

Expected output: each watch item has a "page me if" condition.

### 4. Note in-flight deploys and config changes

What shipped recently, what is shipping during the shift, what was rolled back. Half of all pages trace to something that changed; the handoff should name the suspects in advance.

Expected output: deploys and changes listed with times and owners.

### 5. Record customer commitments with times

"I told [customer] we'd update by 9am," "the status page says all-clear at noon." Commitments outlive shifts, and missing one because the handoff didnt mention it is the most preventable failure in on-call.

Expected output: every commitment has a time and an owner for the incoming shift.

### 6. End with who to call for what

Escalation paths change: who is the backup, who owns the vendor relationship this week, who can approve a rollback. Dont make the incoming engineer search a wiki at 3am.

Expected output: names and contact paths, current for this shift.

## The handoff template

```text
ON-CALL HANDOFF: [date], from [outgoing] to [incoming]

Active incidents:
- [name]: [current state]. Owner: [name]. Next: [action] by [time].
- (or write "none")

Watch items:
- [system or issue]: [why it might page]. Page me if: [condition].

Deploys and changes:
- [what shipped or is shipping]: [time], owner [name].
- [rollback or config change]: [time].

Customer commitments:
- [customer or segment]: [what was promised] by [time].

How to reach people:
- Backup on-call: [name, contact]
- Vendor contact: [name, for vendor X]
- Rollback approver: [name]

Anything else: [free text, or "nothing"]
```

## Variant phrasings

### shift handoff for support on-call

The template above. "Shift" or "on-call," the content is identical.

### how to hand off an incident to the next engineer

Steps 2 and 5, expanded: the incident gets its own mini-handoff (full timeline link, current hypothesis, next action with a time), and it leads the template.

### on-call turnover checklist

Steps 1 through 6 as a checklist. The checklist version works when handoffs keep getting skipped.

## Why it happens

On-call knowledge is perishable: it lives in the outgoing engineer's head, in threads they read, in alerts they half-saw. Without a written handoff, the incoming engineer starts every shift rebuilding context from scratch, and the rebuild always misses something. The template isnt bureaucracy; it is the cheapest possible transfer of the one thing that prevents pages from becoming incidents: knowing what is already in motion.

## Edge cases

- Handoff during an active incident: do a live verbal handoff plus the written template. The written version is the record; the verbal one transfers judgment.
- Nothing happened on the shift: still write the handoff. "Quiet shift, no incidents, no watch items" takes thirty seconds and confirms the silence is real.
- The incoming engineer is new to on-call: add links to the runbooks referenced in watch items. Veterans need names; newcomers need maps.
- Handoff across time zones: write times in both zones or one agreed zone, stated in the header. "9am" without a zone has caused real pages.
- Async handoff with no overlap: the template has to stand alone, so be more explicit in "anything else." Assume no chance to ask follow-ups.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_LLjFiSWkzne_dF8sVN7s6A