On-call Handover Report

A shift can end while an incident, risky change, or watch condition is still moving. The outgoing responder carries details that may not be obvious from an alert title: what has already been tried, which signal matters next, who owns the decision, and where help should come from if the situation worsens.

An on-call handover transfers responsibility for that unfinished work. It should leave the incoming owner able to distinguish urgent items from context, continue the next action without repeating the investigation, and find the live incident record or runbook. A long transcript is not a substitute for a clear owner and a specific next step.

• Incidents and high risks need current state, named ownership, a tracker reference, and an escalation route.
• Changes need timing, validation responsibility, and a rollback or stop condition.
• Watch items and noisy alerts need the signal that would turn observation into action.
• Resolved items need only the context that will help if symptoms recur.

The transfer method should match the risk. A stable queue with complete actions may be handed over asynchronously. Critical or high work usually needs a warm conversation in which the incoming owner acknowledges responsibility and can repeat the next trigger. Posting a note while a severe incident is active can create the appearance of coverage without proving that anyone accepted it.

Time and identity matter as much as content. Include a timezone when responders are in different locations, name a person or queue that can actually act, and avoid vague instructions such as “keep watching.” A useful action names the observable condition and the response, for example checking whether replication lag stays below five minutes through the next backup cycle.

A handover remains a snapshot. Confirm severity, ownership, ticket state, dashboards, and paging routes in their live systems before the outgoing responder signs off. The report should point toward those sources of truth, not replace them.

How to Use This Tool:

Prepare the ownership details first, then add the operational rows that the incoming shift must carry.

1. Paste Handover source rows or load a CSV, TSV, or TXT file. Headers are optional; supported item types include incident, risk, change, watch, noise, resolved, and note.
2. Enter the Team or service queue, outgoing and incoming owners, and Handover time. Include a timezone when the owners do not share one.
3. Choose Warm handover, Async note, or Active transfer. Add an escalation path that names the trigger and destination without including credentials or private paging tokens.
4. Read the readiness result and correct missing owners, next actions, tracker references, or escalation details. If the incoming owner is blank, the handover remains blocked.

Interpreting Results:

Ready to hand over means all seven readiness checks are marked ready for the supplied rows. Review before send means one or two checks need attention. Needs warm transfer means three or more checks are not ready. Blocked pending owner means no incoming owner was named.

A ready label confirms the report’s fields, not the live operational facts. Open the incident, change, dashboard, or runbook references and verify the current state. Treat an async-risk warning as a reason to speak directly when critical or high items remain active.

Technical Details:

Handover rows are converted into a common structure so different queue exports can be reviewed together. The parser detects pipe, comma, tab, or semicolon separation from the first nonblank line. A row is treated as a header when it contains a recognized type field and at least two other recognized fields.

Transformation Core:

The transformation keeps user wording where possible, then fills only the classification needed for ordering and checks.

1. Map header aliases or, for headerless rows with four or more columns, read type, ID, severity, subject, state, owner, next action, and link in that order.
2. Normalize the item type from the declared value or infer it from terms such as incident IDs, change wording, watch verbs, or resolved status.
3. Normalize urgency. Resolved work becomes Closed; SEV0/SEV1, critical, P0/P1, emergency, or outage wording becomes Critical; SEV2, high, P2, blocked, urgent, or customer-impact wording becomes High.
4. Sort by item type, then urgency, then ID. Incident rows lead, followed by risks, changes, watches, noise, resolved items, and notes.
5. Build the acknowledgement sentence and seven readiness checks from the normalized rows and handover settings.

Rule Core:

An active item is any item not classified as Resolved. A hot item is active and normalized as Critical or High. Missing tracker references count only for hot items.

The readiness label follows an ordered decision. A missing incoming owner wins and returns Blocked. Otherwise, three or more non-ready checks return Needs warm transfer, one or two return Review before send, and zero returns Ready to hand over.

Mode-specific warnings do not alter that count. Active transfer with no hot item produces a warning, as does an async note while hot items remain. Those warnings explain a mismatch between the chosen transfer method and the supplied queue.

Limitations and Privacy Notes:

Keyword classification cannot understand the full incident context or confirm that an owner accepted responsibility. Review unfamiliar severity labels, unusual column layouts, inferred types, and any row whose wording is ambiguous.

• The source is limited to 1,048,576 characters, local files are limited to 1 MB, and no more than 500 data rows are accepted.
• Entered rows and loaded text files are processed in the browser.
• Do not paste credentials, private paging tokens, customer secrets, or sensitive bridge access details into a handover report.

Worked Examples:

References:

• Managing Incidents, Google Site Reliability Engineering.
• Being On-Call, Google Site Reliability Engineering Workbook.