On-call Handover Report

Introduction

An on-call handover preserves operational state when responsibility moves from one responder, shift, or location to another. The useful record is not just a list of open tickets. It names the incoming owner, the active incidents, the risky changes, the items that still need watching, and the next action that should happen after the outgoing owner signs off.

Handover quality matters most when a queue is carrying real risk. A high-severity incident without a named owner, a change waiting for rollback confirmation, or a noisy alert without a clear trigger can all look harmless in a short note. The receiving responder needs enough context to continue safely without redoing the whole investigation.

Good handover language stays explicit. The outgoing owner should make it clear who now owns the queue or incident, what evidence changed during the last shift, what remains uncertain, and which escalation path applies if progress stalls. A written record helps, but high-risk work still needs acknowledgement from the receiving owner before the outgoing owner steps away.

The handover report is a preparation aid, not a replacement for the incident system, paging policy, or service runbook. It is strongest when the source rows already reflect current ticket state and when the receiving owner validates the hot items, watch items, and escalation path against live operational channels.

Technical Details:

Operational handover is a state-transfer problem. The receiving responder needs a compact record of scope, ownership, urgency, unresolved work, and escalation. The handover is weak when those details are spread across chat, dashboards, ticket comments, and memory.

The central structure is a row for each item that may affect the next shift. Incidents usually carry the highest transfer risk because they may still affect users or require immediate mitigation. Risks and changes matter because they can turn into incidents after the shift boundary. Watch and noise rows help keep known monitoring context visible without treating every alert as active work. Resolved rows keep recent closure context available without inflating active load.

Rule Core

Rows are interpreted from a delimited source. A header row is optional, and recognized header meanings are mapped into the same handover fields. Without a header, the expected order is type, ID, severity, subject, state, owner, next action, and link.

Urgency is normalized before readiness is calculated. Closed or resolved rows are treated as closed. Severity labels such as critical, P0, P1, Sev 0, and Sev 1 fall into the critical bucket; high, P2, Sev 2, blocked, urgent, and customer-impact wording fall into the high bucket. Medium and low labels use their matching buckets, while active incidents and risks default to medium if no clearer severity is present.

The summary status comes from the checklist. With no source rows, the page asks for handover rows. When all checks are ready, the status becomes Ready to hand over. One or two review checks become Review before send. Three or more review or blocked checks become Needs warm transfer.

The handoff ask is type-aware. Critical or high incidents ask the incoming owner to confirm ownership, tracker, and next action. Risks ask for trigger watch and escalation. Changes ask for validation before the next checkpoint. Noise rows stay conditional: treat them as noise only while the evidence remains stable.

Everyday Use & Decision Guide:

Start with the queue identity and the two shift owners. Team or service queue, Outgoing owner, Incoming owner, and Handover time give the report enough context to stand alone in a ticket, channel, or shift log.

Choose the handover mode based on risk. Synchronous warm handover fits normal shift transfer with active context. Async shift note fits low-risk queue updates, but the page warns when critical or high items are still active. Active incident transfer expects a stronger acknowledgement path, and it warns if no critical or high active item is present.

Paste one source row per operational item. Pipe-separated rows are the easiest to inspect, but comma, tab, and semicolon rows are also parsed. A header row helps when the source comes from a ticket export, yet simple positional rows still work when the first eight values follow the expected order.

• Handover Brief gives a Markdown shift note with readiness counts, grouped items, and the incoming acknowledgement line.
• Coverage Ledger shows each row sorted by type and urgency, with type, ID, urgency, subject, state, owner, and incoming ask.
• Readiness Checklist turns ownership, hot items, next actions, escalation, and changes into ready, review, or blocked rows.
• Handover Load Chart stacks item counts by type and urgency so the receiving owner can see whether the shift is incident-heavy, change-heavy, or mostly watch context.
• JSON preserves the same summary, ledger, checklist, chart rows, warnings, and Markdown text in structured form.

A clean-looking brief still needs a human check. Confirm that high-severity rows have current tracker links, that the escalation path is the one the incoming owner can use, and that every next action is observable enough for the receiving shift to know whether it happened.

Use the report as a handover record before sign-off. For active incidents, keep the bridge or shift channel open until the incoming owner has repeated back hot item ownership, the next actions, and the escalation route.

Step-by-Step Guide:

Work from shift identity to source rows, then review the checklist before copying the brief.

1. Enter the Team or service queue so headings and exported records identify the receiving queue clearly.
2. Fill Outgoing owner, Incoming owner, and Handover time. Leave the incoming owner blank only when the assignment is genuinely pending, then treat the blocked readiness row as a stop cue.
3. Select Handover mode. Use async only for low-risk notes, and use active incident transfer when hot items need live acknowledgement.
4. Add Escalation path with the bridge, paging policy, commander, manager alias, or channel that the incoming owner should use when stuck.
5. Paste or drop the source rows. Use columns for type, ID, severity, subject, state, owner, next action, and link when available.
6. Use Normalize rows after parsing if the source should be cleaned into a consistent pipe-delimited layout before export.
7. Read the warning panel and Readiness Checklist. Fix missing owner, missing next action, blank shift identity, and risky mode warnings before relying on the brief.
8. Review Handover Brief, Coverage Ledger, Handover Load Chart, and JSON for the record format needed by the next shift or incident process.

Interpreting Results:

Read the readiness label before copying the report. Ready to hand over means the entered rows have a named incoming owner, no hot-item review cue, no owner gaps, no missing actions, an escalation path, and no change-awareness review. Review before send means one or two checks still need attention. Needs warm transfer means the handover has enough risk or missing context that a live acknowledgement is the safer path.

The hot count is deliberately conservative. Critical and high active rows are counted regardless of whether the subject looks stable, because a high-risk ticket still needs ownership, tracker context, and a next action at shift boundary. Resolved rows do not count as hot active items, but they remain useful context if symptoms return.

The chart is a load map, not a severity decision. Use it to see whether the handover is dominated by incidents, changes, risks, or watch context, then use the ledger and checklist to decide what needs a direct acknowledgement.

Worked Examples:

Active incident transfer:

A row such as incident | INC-1021 | SEV2 | VPN latency after carrier flap | stable after route change | Network primary | Watch p95 latency and reopen carrier ticket if loss exceeds 2% | status link is treated as a high active item. The readiness checklist asks for review, and the acknowledgement line expects the incoming owner to repeat back hot item ownership and escalation before bridge transfer.

Low-risk async shift note:

If the source contains only low watch, noise, and resolved rows with owners and next actions, Async shift note can be a reasonable mode. The receiving owner should still acknowledge in the shift channel, especially when a watch item has a timed confirmation such as backup completion by 20:00.

Missing owner and action:

A row with a subject but no owner or next action can still appear in the ledger, but it is not handover-ready. The warning panel counts owner and action gaps, the row ask tells the outgoing owner to add a clear next action, and the checklist keeps the report in review until the gaps are fixed.

Change-heavy queue:

Several medium change rows may not create a hot-item count, but they still create a change-awareness review. Use that cue to confirm rollback image, validation owner, propagation state, branch contact, or cutover timing before the next shift takes the queue.

FAQ:

Glossary:

Handover

The transfer of operational responsibility from one responder, shift, or queue owner to another.

Hot item

A critical or high active row that needs direct attention before the handover is safe.

Incoming ask

The action or confirmation the receiving owner should take for a row.

Warm handover

A live or synchronous transfer where the incoming owner explicitly acknowledges ownership and next actions.

Coverage ledger

The row-by-row table that keeps type, urgency, subject, state, owner, and handoff ask together.

Watch item

A condition that is not necessarily an active incident but still needs monitoring, confirmation, or follow-up.

References:

• Google SRE, Managing Incidents
• Google SRE, Incident Management Guide
• Google SRE Workbook, On-Call