Incident Timeline Report

Incident notes arrive from alerts, bridge messages, tickets, dashboards, command output, and memory. Until those fragments share a time basis and evidence reference, responders can disagree about what happened first, how long a gap lasted, or which action actually changed service behavior. A timeline gives the review a common chronology without pretending that sequence alone proves cause.

Useful events answer four questions: when did it happen, who acted or observed it, what changed, and where can another reviewer verify it? Confidence belongs beside the event when the fact is provisional. A statement such as “database saturation suspected” should not silently become “database saturation caused the outage” because a later row mentions recovery.

• Detection records the alert, ticket, or report that made the incident visible.
• Containment records the action that stopped impact from expanding.
• Recovery records restored service and validation, not merely the start of a repair.
• Triage, impact, communication, and review add context when they occurred, but not every incident needs every optional phase.

Time normalization needs an explicit rule. A short value such as 08:15 has no date or offset, so it must be anchored to an incident date and described with a time-basis label. A full timestamp with an offset carries its own absolute time. Mixing local clocks, UTC, and copied log timestamps without labeling them can reverse events or create a false gap.

Quiet periods deserve inspection because missing bridge updates can hide decisions, customer impact, or the moment mitigation took effect. They are not automatically failures. The expected update cadence varies by severity and response process, and a gap exactly equal to the selected threshold stays within cadence. Only a strictly greater adjacent gap is flagged.

The finished chronology should remain a review artifact, not a substitute for raw evidence. Keep sensitive logs and captures in their approved evidence store, link or identify them from the timeline, and preserve uncertainty until the review supports a stronger conclusion.

How to Use This Tool:

Prepare one incident source set with timestamped rows. CSV, TSV, pipe-delimited, and semicolon-delimited text are accepted, with or without recognized headers.

1. Paste Timeline events or load one CSV, TSV, or TXT file no larger than 1 MiB. Preferred columns are time, phase, actor, event, source, confidence, evidence, and notes.
2. Set the Incident date and Time basis label. Short times use that date; full timestamps retain their explicit date and offset.
3. Add the Incident ID, affected service, severity, impact summary, and a Long gap threshold from 1 to 240 minutes.
4. Keep root-cause wording confirmed, suspected, or pending. Add follow-up actions only when they are real review candidates.
5. Generate the report. Correct skipped source rows, missing Detection, Containment, or Recovery evidence, and events that lack both an explicit source and an evidence reference.
6. Use the selected Report audience to shape the closing handoff, then move accepted actions into the team's durable tracker.

Interpreting Results:

Ready means the corresponding review rule found no gap. Review appears for skipped rows, missing required phases, long adjacent gaps, absent explicit evidence, Low confidence events, a blank root-cause statement, or no follow-up actions. These findings identify documentation work; they do not grade incident handling.

The supported percentage counts events with either an explicit source or a non-empty evidence reference. A default source label fills the displayed Source cell but does not make a row supported. This prevents a convenient fallback label from overstating evidence coverage.

A long-gap marker means the interval is greater than the selected threshold. It may reveal a missing update, or it may be an expected quiet period. Add the omitted event when evidence exists; otherwise explain the silence rather than inventing activity.

Technical Details:

Rows are parsed with the delimiter that produces the most cells. A recognized header requires both a time column and an event column; header aliases map common names such as timestamp, owner, description, system, certainty, and ticket. Without a header, positional layouts with three, four, five, or at least eight cells are interpreted in defined orders.

Transformation Core

1. Normalize line endings and remove blank lines.
2. Parse the timestamp, event text, optional phase, actor, source, confidence, evidence, and notes.
3. Skip rows without a usable timestamp or event, then sort valid events by absolute time and original row order.
4. Infer missing phases from event vocabulary and normalize confidence to High, Medium, or Low.
5. Calculate elapsed time and adjacent gaps, then build phase coverage and seven review findings.

Explicit phase names take precedence over inference. When a phase is absent, alert and paging words map to Detection; mitigation and rollback words to Containment; restore and stable words to Recovery; investigation words to Triage; impact words to Impact; stakeholder updates to Communication; and post-incident or action terms to Review. Unmatched events default to Triage.

Timestamp rules

Time-only rows are anchored to the entered incident date. If a later short time would move backward by more than six hours, one day is added repeatedly until the sequence is plausible; this supports incidents crossing midnight. Full timestamps accept a calendar date, optional time, and optional Z or numeric offset. A full timestamp without an offset is interpreted as UTC, while the time-basis label remains descriptive and never rewrites it.

Formula Core

An event is supported when it has an explicit source or an evidence reference. The supported percentage is not rounded before use.

Elapsed and gap values use timestamp differences in minutes.

Rule Core

Privacy Notes:

Timeline parsing and report generation stay in the browser. Files and pasted text can still contain customer names, internal hostnames, responder identities, ticket links, security findings, or raw evidence references, so use an approved device and distribution channel.

Keep raw logs, packet captures, credentials, personal data, and sensitive customer detail out of the summary unless the report's access controls permit them. Prefer stable evidence identifiers over copied payloads, and sanitize the exported review before sharing it beyond the incident team.

Worked Examples:

References:

• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, National Institute of Standards and Technology, April 2025.
• Postmortem Culture: Learning from Failure, Google Site Reliability Engineering Workbook.
• How to collect network evidence during incident triage, Simplified Guide.