Best for
- Post-incident confusion about what happened when
- Evidence scattered across six tools and three chat channels
- The factual spine a postmortem needs before analysis can start
What you give it
- The evidence sources: log extracts, alert records, chat transcripts, deploy history, people's recollections
What you get back
- One sequenced timeline: every event timestamped, sourced and classified (system event, human action, communication)
- Conflicts resolved or marked: when sources disagree, the discrepancy is shown, not smoothed
- The derived numbers: detection gap, response gap, resolution time — computed from the record, not the memory
How it works
- Normalises all sources to one clock (time zones and skew handled) before sequencing anything.
- Prefers machine evidence for when, human evidence for why — and labels which kind backs each entry.
- Classifies entries so patterns show: system events, human actions, communications, decisions.
- Computes the gaps that matter from the record: detection, acknowledgement, diagnosis, resolution — the incident's vital signs.
Example
You: Reconstruct Saturday's database incident from these logs, the pager history and the two chat channels.
Result: The timeline: 47 events from 03:02 (first slow-query log line — twelve minutes before the first alert, a detection finding in itself) to 06:51 (verified recovery). Each entry sourced; the chat's 'restarted it around 4' resolved to 04:17 by the process log; one genuine conflict marked (two accounts of who approved the failover — both kept, flagged). Derived: detection 12m, first response 9m, the 31-minute diagnosis detour down the wrong hypothesis visible as a block. The postmortem wrote itself on top.
Limits — please read
- Evidence that was never recorded cannot be reconstructed; gaps are shown as gaps (and become monitoring findings).
- Clock skew across systems is corrected where provable, noted where not.
- The timeline is the factual spine; causes and judgements belong to the postmortem built on it.