LearnGrokYou need a handover that lets the next engineer make the next decision, not one that retells the shift. Use these prompts to turn alerts, incident-channel messages, open investigations and recent changes into a note with a current status, named ownership and clear triggers.
Start with the first prompt while the outgoing engineer can still answer questions. Use the later prompts only when new information, conflicting evidence or an unclear decision needs attention.
Key point
Write for the next decision
A useful handover says what is true now, what remains uncertain, who acts next, and what observation changes the plan.
1. Collect the source material
Before you paste anything, gather the material from the same shift and record the end time and timezone. The first prompt works best when the inputs are separate, rather than one large unlabelled transcript.
Include:
- The alert export or a concise list of alert names, firing times, severity and current state.
- Incident-channel updates, including message timestamps and named owners.
- Investigation notes, such as a dashboard observation, trace finding or attempted mitigation.
- Production changes made during the relevant period. Include deployments, configuration changes, feature-flag changes and rollbacks.
- The previous handover, where the current incident began before this shift.
Remove credentials, access tokens, personal data and customer content that the next engineer does not need. Keep incident IDs, service names, timestamps and change references. They are the details that make the note actionable.
Watch out
Do not paste an alert without its time
A firing alert from earlier in the shift can look current if the timestamp is absent. Preserve the timezone as well.
If you use attachments or long source material, check the current product guidance first. Input handling and available limits are version-dependent. See the xAI documentation overview.
2. Draft the full note first
Run Build the first handover note once you have the inputs. It produces the complete document, not a summary paragraph. Read the Service status table before anything else. Every service should be explicitly healthy, degraded, unavailable or unknown.
Do not force a service into healthy because no new alert arrived. If the available evidence cannot establish its state, unknown is the correct handover status. This is especially important after an alert clears without an investigation confirming why it cleared.
The Next checks section is the working part of the note. Each item needs a concrete place to look, an expected result, an owner and a timing. Replace a vague instruction such as “check errors later” with the service, signal and decision that follow from the result.
Check
The first draft is usable when
An incoming engineer can identify the affected service, find the next check, see who owns it, and know what would trigger escalation without opening the incident channel.
3. Deal with late updates without losing history
Do not rebuild the note from scratch when an alert fires again or an investigation result arrives just before handover. Use Add late incident updates. It retains confirmed earlier facts and gives you a change log showing what moved.
Read the Superseded statements section carefully. A channel message may correct an earlier assumption, but it may also simply be a later hypothesis. If two statements disagree, keep both in the record until evidence resolves them.
Send the revised handover, not just the change log. The next shift should receive one current document. The change log is there to help the incident lead understand why the document changed during the last part of the shift.
4. Make conflicts visible
Use Resolve handover conflicts when the monitoring signal, channel discussion and deployment record point in different directions. Typical examples include an error-rate alert that has cleared while users still report failures, or a deployment timestamp that does not match the first observed impact.
The aim is not to pick the most plausible explanation. The aim is to state the safe operating position and name the check that resolves uncertainty. A causal link between a change and an incident stays a hypothesis unless the evidence supports it.
This prompt is also useful for ownership gaps. If a task has no named person or team, leave it as owner unassigned. An invented owner creates a worse handover than an explicit gap.
5. Convert investigation into decisions
A handover can contain accurate facts and still fail if nobody knows what to do next. Run Set next checks and escalation triggers when the incident lead needs a decision-ready plan.
Use the output to replace generic watch items in the main note. Keep only checks with a decision attached. An escalation trigger should contain the condition, the evidence to gather, the destination and the urgency. If the contact route or threshold is not known, show that as a gap rather than filling it from memory.
Note
Separate observation from action
“Queue depth increased” is an observation. “Inspect queue depth after the next deploy, then pause the change if it remains above the agreed threshold” is an action with a decision point.
6. Check what could be wrong
Run Check the final handover before you send it. Look first for statements that sound settled but lack evidence: “resolved”, “caused by”, “no user impact” and “being handled” all need a timestamp, source or named owner.
Also check that the handover distinguishes current state from past activity. A list of alerts is not a service-status assessment. A list of names is not ownership unless each person has a stated action.
| If you see this | Treat it as | What to do |
|---|---|---|
Seems resolved |
Unsupported conclusion | Add the confirming signal and timestamp, or mark status unknown |
Team is looking |
Missing ownership | Name the owner and the next action, or write owner unassigned |
| Two different timestamps for impact | Material conflict | Use the conflict prompt and state what evidence will resolve it |
Monitor overnight |
Vague next check | Name the signal, timing, expected result and escalation trigger |
When it does not work
If the output is too general, do not ask for “more detail”. Add the missing source field, such as the alert timestamp, deployment reference or owner, then rerun the relevant prompt. If the material is contradictory, use the conflict prompt rather than asking for a cleaner narrative.
If essential information is unavailable, send a shorter handover that explicitly marks the unknowns and assigns the first fact-finding check. A clear gap is safer than a confident reconstruction.
