Start with impact and responsibility
| Field | Initial entry |
|---|---|
| Observed impact | New bookings fail; existing bookings remain readable |
| Unknown | Whether any timed-out request created a booking |
| Response lead | Assigned duty lead |
| Change owner | Assigned operations colleague |
| Current action | Inspect failed requests before replaying |
| Next update | At the locally agreed checkpoint |
Write observations separately from hypotheses. “Started after the release” is timing evidence, not proof that the release caused the outage. Google’s incident guidance separates coordination, operations and communications; a small team can combine roles if everyone knows who holds them.
Keep a decision trail
Before a change, record the intended effect, owner and verification. After it, record the observed result. Stop uncoordinated changes so a second responder does not unknowingly undo the first. Preserve relevant logs with controlled access, without pasting private customer data into broad updates.
A workaround restores new bookings but uncertain earlier requests remain. Can the incident record close immediately?
Show the worked answer
Record restored service and the remaining reconciliation task separately. Assign the uncertain requests and verify the agreed closure conditions; a working screen does not resolve possible missing or duplicate records.