Record facts separately from guesses
Start an incident note with what was observed, when it was observed and where it was observed. “Requests timed out from the public endpoint at 09:12 UTC” is more useful than “the network is broken”. Keep suspected causes in a separate paragraph.
Record the clock and time zone used by each evidence source. If two systems disagree about time, note the difference. A tidy chronology built from inconsistent timestamps can be misleading. Preserve the original evidence in an appropriately restricted location.
Collect only what helps the investigation
OWASP’s logging guidance discusses useful security events and the need to protect sensitive information in logs. The same care applies when sharing an incident excerpt: credentials, session tokens and personal data should not be pasted into a general chat.
Create a short evidence index rather than repeatedly reposting entire files. Each entry should identify the source, time interval, relevant observation and person who collected it. Where retention is limited, preserve authorised evidence before it rotates away. Follow your organisation’s handling rules.
Track interventions as carefully as symptoms
Write down each change, its purpose and the observed result. When several people are working, this is how you avoid mistaking one person’s intervention for another person’s discovery. If possible, assign one incident lead to coordinate changes.
After service returns, distinguish the action that restored service from the explanation of why it failed. A restart can end a symptom without confirming its cause. Close the note with unresolved questions, evidence locations and follow-up owners. Avoid retroactively editing the timeline to make the investigation look more certain than it was.
Before you finish
- Observations separated from hypotheses
- Time zones recorded
- Sensitive values excluded
- Interventions included in the timeline
Technical reference
OWASP: logging cheat sheet