A small incident record that helps the next responder
Capture decisions and evidence without filling a giant form.
Record the first known symptom
Write the affected task, first observed time and how the issue was detected. Separate the time an incident started from the time someone noticed it. If the start time is uncertain, say so rather than inventing precision.
Build a factual timeline
For each significant event, record time, observation, action and result. Identify which deployment or configuration was involved without copying secrets. A hypothesis belongs in the record as a hypothesis until evidence supports it.
Verify recovery through the user task
A process restarting is not the same as a customer completing the affected task. Check the actual flow and record the evidence used to declare recovery. Monitor for recurrence over an appropriate period and identify who owns follow-up.
Turn the record into one practical improvement
Choose an action that addresses the demonstrated failure: a clearer alert, a safer rollback, a missing test or a corrected runbook. Include an owner and completion condition. Avoid a long list of vague promises that cannot be checked later.
Common questions
What should a small incident record include?
Write the affected task, first observed time and how the issue was detected, then build a factual timeline: for each significant event, record time, observation, action and result. Separate the time an incident started from the time someone noticed it, and say so if the start time is uncertain rather than inventing precision.
How do we know the incident is actually over?
A process restarting is not the same as a customer completing the affected task. Check the actual flow and record the evidence used to declare recovery. Monitor for recurrence over an appropriate period, and identify who owns follow-up, so recovery rests on evidence rather than on the process state alone.
What should the record produce?
One practical improvement that addresses the demonstrated failure: a clearer alert, a safer rollback, a missing test or a corrected runbook. Include an owner and a completion condition. Avoid a long list of vague promises that cannot be checked later — the record exists to help the next responder.
Keep working through the question
Unkillable Window · Published . Updated . Prepared with AI assistance; editorial approach and corrections are described on our method page. Examples are illustrative, not case-study results.
References and further reading
- Google SRE Book: managing incidents — Incident roles, declaration, the living incident document and postmortem practice. The record structure above is our own.