On-call handover from overnight incidents

Use one structured handover log to turn an overnight queue into work the next shift can act on. This is for the engineer ending a production support shift, especially when alerts, incident notes and tickets disagree or leave gaps.

The aim is not a polished incident summary. The next engineer needs four things: current impact, a named owner, checks still due, and a short priority order.

1. Collect a bounded shift snapshot

Set a clear cut-off time before you gather anything. Write it at the top of your notes, including the timezone. Collect only items that were active during your shift or need follow-up after it:

• Alert titles, start times, current state and affected service.
• Incident channel notes or incident record updates.
• Open tickets linked to production work.
• Deployment, rollback or mitigation notes that change current risk.
• The existing handover log, if there is one.

For each source, retain its link or identifier. Do not rely on copied prose alone. A ticket can be updated after you read it, and an alert may recover while the underlying fault remains.

If your workspace supports attachments or connected sources, the available methods can vary by version. Check the xAI documentation overview before changing a team workflow around them.

2. Normalise each item before asking for a handover

Make a short source list. One row per alert, incident or ticket is enough. Add fields rather than trying to resolve contradictions in your head.

Field	What to record	Example form
Reference	Alert, incident or ticket ID	INC-184, OPS-291
Last confirmed time	Most recent evidence, with timezone	02:14 UTC
Current state	Active, mitigated, monitoring, or unknown	Monitoring
Impact	Observed user or system effect	Checkout latency elevated
Owner	Named person or team from a source	Payments on-call
Pending check	Test, threshold or decision still needed	Check error rate after traffic peak

Use unknown where the evidence does not support an answer. This is better than converting a plausible guess into an assignment for the next shift.

3. Generate a constrained draft

Paste the source list and the relevant excerpts into the conversation. Ask for a log in a fixed format, with a rule that it must not invent ownership, impact or completion. Use this prompt:

Create an on-call handover log for the next shift.

Cut-off time: [DATE AND TIME, TIMEZONE]

Use only the evidence below. If evidence is missing or conflicts, write `Unknown` and name the missing source or conflict. Do not infer an owner.

For each active or follow-up item, include:
1. Reference and service
2. Current impact, stated as of the last confirmed time
3. Current state: Active, Mitigated, Monitoring, Resolved, or Unknown
4. Named owner or owning team, with source reference
5. Pending check, including what result would count as complete
6. Next action and priority: P1, P2, or P3
7. Source references

Then add:
- A `Next shift priorities` section with no more than three actions, ordered by urgency.
- A `Questions to resolve` section for missing owners, unclear impact, conflicting timestamps, and expiring mitigations.

Keep resolved items out unless they require a follow-up check.

Evidence:
[PASTE NORMALISED SOURCE LIST AND EXCERPTS]

The fixed states prevent vague phrases such as “looks better”. The completion condition on a pending check prevents the next shift from repeating an observation without knowing what decision it supports.

4. Check the draft against the sources

Read the generated log beside the source list. Check each listed item, not just the priority section. You are looking for unsupported certainty and stale status.

First, verify the last confirmed time. A recovered alert from early in the shift must not override a later incident update. Next, follow each source reference and confirm that the stated owner is actually named there. Finally, make sure each pending check has a measurable result, a time to revisit it, or a clear person or team to contact.

Use this table when a line looks wrong:

If you see	Likely problem	What to do
“Monitoring” with no threshold or review time	A status label replaced a plan	Add the metric, expected range and next review point from the incident record.
A person named as owner with no source	The draft inferred responsibility	Replace with the listed team or Unknown, then add an ownership question.
“No customer impact” after an incomplete investigation	An absence of evidence became a conclusion	State what was checked and mark impact as unknown if evidence is incomplete.
Several urgent priorities	The log is a backlog, not a handover	Keep the first three executable actions. Move the rest into item-level next actions.

5. Publish the log, then make one final delta update

Put the checked draft in the team’s handover location. Keep the source references intact so the next engineer can verify a claim without searching chat history.

Just before the shift change, recheck for meaningful changes: a new page, a rollback outcome, an owner reply, or a ticket state change. Do not regenerate the whole log for a minor edit. Update the affected line, change its timestamp, and add a short Delta since draft note. This makes it clear what changed after the original cut-off.

During the handover conversation, start with the three priorities. Then cover items with an unknown owner, an active impact, or a check due soon. The incoming engineer should leave knowing which source to open first.

When the draft does not work

If the output is too broad, reduce the evidence to active items and open follow-ups, then repeat the same fixed prompt. If it omits an item, add the item’s reference and latest update explicitly rather than asking for a more general summary.

If the sources conflict, do not ask the model to decide which is true. Record both timestamps, mark the field as unknown, and assign the next shift a verification action. If ownership is unclear, route the question through the team’s normal escalation path and leave the gap visible in the log. A visible gap is safer than a confident but wrong handover.