During an interruption, notes arrive out of order. Someone notices an error, another person reports a change made earlier, and a third person suggests a possible cause. If all three are placed into one unlabelled paragraph, the resulting timeline can imply a sequence that nobody actually observed.
A useful incident note separates event time, observation time, source, and confidence. It also leaves room for correction. This guide uses a fictional publishing preview that becomes unavailable. It is an example of record keeping, not an account of a real outage or a substitute for your team's incident response procedure.
Give the record a common clock
Choose an explicit time zone for the timeline and put it near the title. “15 October, UTC” is clearer than a sequence of bare times. Preserve the original time zone when copying a source, and label a conversion if you make one. Do not silently treat a timestamp from a different location as local time.
If an exact event time is unknown, write a range or “time not established.” A precise-looking minute can be more misleading than an honest gap. The timeline should distinguish what the team knows from what it hopes to infer later.
Separate occurrence from discovery
Suppose a fictional editor reports at 14:12 UTC that the preview failed when opened around 14:08. The report was received at 14:12, while the reported occurrence was around 14:08. Keep both values instead of choosing one and losing the distinction.
That matters when comparing the failure with a change made at 14:10. A report received after the change is not evidence that the failure began after it. Chronology helps investigate a cause, but it does not establish causation by itself.
Use one event per entry
Each row should answer what happened, when, how the team knows, and what remains uncertain. Avoid bundling an observation and a theory into the same sentence. You can keep a separate hypotheses section where possible explanations are listed with the evidence needed to assess them.
Fictional entry:
Event time: About 14:08 UTC, reported by editor.
Recorded at: 14:12 UTC.
Observation: Preview returned an error page on first opening.
Source: Editor's message in the agreed incident channel.
Confidence: Reported; not independently reproduced at this point.
Follow-up: Check a harmless preview sample and record the result.
The confidence label describes the evidence, not the reliability of the person. “Reported” and “directly observed” are useful distinctions. Neither requires a judgment about a colleague's competence or intentions.
Keep actions and results connected
When someone takes an action, record its intended purpose separately from its result. “Restarted preview worker to restore access” describes an attempt. “Preview loaded in the next check” describes an observation after that attempt. The second statement should include the check time and scope.
Do not write “resolved” merely because an action completed successfully. A command finishing or a setting being saved may not mean users can complete their work. Record the actual recovery check, such as opening the preview and viewing the expected draft, and retain any conditions that were not checked.
Preserve corrections visibly
A timeline often improves as more evidence becomes available. If a reported time changes, append a correction with its source and the time the correction was made. Mark the earlier entry as corrected rather than erasing it without explanation.
For example: “At 14:35 UTC, editor confirmed the first attempt was 14:06, not 14:08, using a saved message.” This keeps the original investigation understandable. Readers can distinguish what the team knew during the interruption from what it learned afterward.
Put sensitive detail somewhere appropriate
An incident note may refer to logs, account activity, or private documents. Keep the general timeline shareable and link to restricted evidence through the team's established system. Do not paste credentials, tokens, customer text, or unreviewed log dumps into an ordinary browser note.
A short source description is often enough for the timeline: “restricted request log, entry identifier X.” The evidence itself should remain in the place designed to control its access and retention. A convenient drafting surface is not automatically a suitable incident archive.
Close with remaining uncertainty
A closing summary can state the observed impact, recovery checks, unresolved questions, and follow-up owners. Keep the cause provisional if the evidence has not established it. “Access restored; cause under investigation” is more accurate than an elaborate explanation assembled from timing alone.
When the incident ends, make a stable copy of the record and move agreed actions into the team's task system. The timeline should support a later review without being forced to perform every role at once. Its value comes from traceable observations and honest gaps, not from the appearance of a perfect story.
A final review before sharing
Read the entries in time order, then read them in the order they were recorded. Check whether either sequence could imply more certainty than the evidence supports. Confirm that every claimed recovery has a corresponding check and that every correction is visible. This small review makes the note easier to use when memories have faded.
Use the BiNotePads online notepad to adapt this example. For a separate copy of important work, follow the browser-note backup guide.