Incident handover records
Build an incident record with a live summary and an append-only timeline
Keep the current operating picture easy to find while preserving how it changed. Link actions to owners and evidence rather than burying them in narrative updates.
In this article
Give the incident a stable home
Create an incident identifier and a shared record accessible to the response team under the appropriate information policy. Link the working channel, dashboards and affected service references.
Put the current impact, incident lead and next update time at the top. Store the timeline separately so adding historical detail does not push the current state out of view.
This synthetic state illustrates the information a handover needs. It is not an automated command to change production.
{
"incidentId": "incident-example-26",
"observedAt": "2026-09-11T03:20:00Z",
"impact": "Orders accepted, dispatch delayed",
"activeMitigation": "Dispatch concurrency reduced",
"unresolvedOrders": 14,
"nextAction": "Reconcile uncertain payment outcomes before replay",
"owner": "incoming-incident-lead"
}Capture decisions when they are made
For each material action, record the time, actor, purpose and observed result. Distinguish a proposed change from an executed one and a successful command from a verified business recovery.
Keep hypotheses labelled. If evidence later disproves one, update its status while retaining enough history to explain why the team pursued it.
Use unambiguous timestamps with offsets or UTC in the record. Teams working across Australian time zones should not have to guess which local clock a bare time represents.
Track temporary state explicitly
Maintain a short list of paused jobs, feature flags, altered limits and emergency permissions. Give each a reversal condition and owner.
Link exact configuration revisions or change records where available. A note saying “scaled it up” is difficult to undo safely when several components changed during the incident.
Make handover an acknowledged transition
The outgoing owner refreshes the summary, then the incoming owner confirms impact, active changes and next action. Record acceptance and the new update time.
Keep unresolved reconciliation and follow-up tasks linked when the incident is stabilised. The working record can then become evidence for the later review without pretending that all corrective work finished at the moment service returned.
Primary sources
Google SRE: managing incidentsGoogle SRE: postmortem cultureReferences checked 11 September 2026.