Software projects
Turn incident notes into a factual timeline
Put each event in order with its timestamp and time zone, then record what was observed or done and where the evidence is. Keep explanations for later. A timeline that mixes facts with theories about cause is hard to trust and harder to correct.
Incident name or reference: [ ] System affected: [ ] Sources used for this timeline: [ ] Timestamp: [ ] Time zone: [ ] Observation: [ ] Action taken and by whom: [ ] Evidence location: [ ] Uncertainty or conflict: [ ] Confirmed by: [ ] Gaps with no record, from [ ] to [ ] Duplicate or conflicting timestamps: [ ] Interpretations added later, kept separate: [ ] Status of each (confirmed or hypothesis): [ ]
Facts mixed with interpretation
Scan for sentences that explain instead of report, such as "the deploy broke the cache." Those belong in a separate list of hypotheses. Check that every entry names its time zone, since notes from different tools and people often differ. When two sources give different times for the same event, keep both and say so. Attribute an action to a person or system only when your notes say so, and mark stretches where nothing was recorded instead of filling them with likely events.
Separate confirmed events from later interpretations in this timeline. List entries that explain cause instead of reporting observation, and point out missing time zones, duplicate timestamps and conflicting times for the same event. Do not resolve conflicts or propose a cause.
Verify before sharing
Check the timeline against the original logs, alerts or messages and replace paraphrases with exact timestamps where you can. Ask people who were involved to confirm entries about their own actions. Put hypotheses in a separate section, labeled as unconfirmed. Share the timeline before any cause analysis begins, so the analysis starts from agreed events.