LearnGrokYou need one record that survives a shift change. Start by extracting evidence, then order it, challenge it, and write the handover from the checked version. This is for on-call engineers, incident commanders and engineering leads handling an active or recently closed incident.
The aim is not a polished narrative. It is a record that separates what the systems showed from what people reported, and makes the next owner clear.
Key point
Keep evidence separate from conclusions
A timestamped alert can support an alert state. It does not, on its own, prove customer impact, root cause or recovery.
1. Gather the source material
Collect the material before asking for a timeline. Use the smallest useful extract, but retain timestamps and the context around each key message.
Include:
- Alert history, including trigger and clear times, alert names, thresholds and affected service.
- Incident-channel messages, especially declarations, impact reports, mitigation decisions and ownership changes.
- Dashboard readings recorded during the incident, with the metric name, value and observation time.
- Operator notes, deployment records, rollback records, feature-flag changes and traffic changes.
- The current state of alerts and the latest dashboard observation.
Remove secrets, access tokens and credentials. Replace customer names or identifiers if they are not needed to establish impact. Do not paste an entire channel merely because it is available. Include messages that establish a fact, a decision, an action, a claimed recovery, or a disagreement.
Stop
Do not treat chat as the system of record
A message saying a deployment fixed the problem is a report until a timestamped deployment record and service evidence support it.
Use Extract evidence from incident sources when the raw material is mixed. It gives each statement a source ID. Those IDs matter later. They let a reviewer trace a timeline row back to the alert, message or note that supports it.
If your incident spans regions or teams, retain the timezone shown in the source. Convert only when you know the source timezone and the display timezone. A confident but wrong conversion can reverse the apparent order of a rollback and a recovery signal.
2. Build the event order
Paste the evidence register into Build the factual incident timeline. Set the start boundary first. For a customer-impact incident, use the first confirmed customer impact where possible. For an operational event with no confirmed impact, use the first known signal and say that impact is not established.
The timeline distinguishes five useful event types:
| Status | Use it for | Do not use it for |
|---|---|---|
observed |
Alert, metric or user report | A conclusion about cause |
action taken |
An operator action | The effect of that action |
change made |
Deploy, rollback or configuration change | Proof the change resolved the incident |
recovery signal |
A metric, alert or impact signal improves | A final closure claim without sufficient observation |
decision |
A recorded choice and owner | An implied decision |
Keep the timeline narrow. A handover reader needs to find the first impact, each mitigation attempt, every material change, and the latest state. They do not need greetings, repeated status updates or speculation from the channel.
Check
Check the boundaries before sharing
The record should show a source for the first signal, first impact, mitigation start and recovery. If any is missing, say not established.
3. Resolve uncertainty without hiding it
Run Reconcile conflicting incident evidence whenever the evidence tells more than one story. Common examples include an alert clearing before users report recovery, a dashboard aggregation masking a regional failure, or a chat message claiming that a rollback worked before its completion time is recorded.
Do not force a single answer. Replace unsupported certainty with wording that says what is known. For example, change “the rollback restored service” to “the error-rate alert cleared after the rollback; customer-impact end time is not established”. This is more useful to the next engineer because it tells them what still needs checking.
The reconciliation output also gives the incident commander a short verification list. Assign those questions to the person or role able to inspect the missing evidence. Do not assign ownership by guessing from who spoke most in the channel.
4. State what changed and what is true now
Use Record changes and service state after the timeline has been checked. It prevents a common handover failure: listing actions without saying which changes remain active.
For every deploy, flag change, scale adjustment or manual intervention, record both the expected and observed effect. If the service improved after a change but the evidence does not isolate that change, write effect not established. Several actions may have happened close together.
Use stable only when the supplied observations support it. If the latest data is old, alerts are quiet but the key metric is missing, or a mitigation is still settling, recovering or unknown is safer.
Watch out
Alert clearance is not necessarily recovery
An alert can clear because traffic changed, a threshold was crossed, telemetry failed or the affected scope narrowed.
5. Produce the handover record
Run Write the on-call handover record last. Paste the checked timeline and the change-and-state record, not the original chat log. This reduces repeated interpretation and makes the handover concise enough to use during a live shift change.
Read the Situation now section first. Then check that every action has an owner and due time, and that the Next decision owner is a real role or named person. If ownership is unknown, leave it explicitly unassigned and ask the incident commander to assign it.
The model's available behaviour and limits can vary. Check the current guidance in the xAI documentation overview before relying on a workflow for a critical incident.
When the record does not work
If the output has invented a time, cause or owner, return to the evidence register and ask for the source ID. Remove any claim that cannot be traced. If the ordering is unclear, retain both events with their recorded times and mark the order as unresolved. If the current service state is vague, collect one fresh dashboard observation and the current alert state, then rerun the service-state and handover prompts. Do not close the incident record by making uncertainty sound like recovery.
