Incident Timeline Report

Incident ID:

Use the ticket, bridge, PIR, or case identifier.

Affected service:

Keep it short enough to scan in report titles and export filenames.

Severity:

Choose the incident severity used by your response process.

Incident date:

Required for time-only timeline rows; full ISO timestamps keep their own date and offset.

Time basis label:

This labels the report; ISO timestamps with offsets keep their parsed instant.

Long gap threshold:

Use the response cadence expected during active incident command.

min

Impact summary:

State what was degraded, who was affected, and the current status.

Timeline events:

Paste incident notes as CSV, TSV, pipe, or semicolon rows; parsing stays in this browser.

{{ events.length.toLocaleString() }} chars

Root cause:

Add the best current cause statement; keep unknowns explicit.

Follow-up actions:

Use concrete actions that belong in the post-incident review or action tracker.

Review timeline inputs

{{ message }}

Report audience:

Pick the review context for the generated report wording.

Default source:

Use a bridge log, incident channel, ticket system, or runbook note label.

Review owner:

Optional team or person responsible for carrying the review forward.

Time	Elapsed	Gap	Phase	Actor	Event	Source	Confidence	Evidence	Copy
{{ row.time }}	{{ row.elapsed }}	{{ row.gap }}	{{ row.phase }}	{{ row.actor }}	{{ row.event }}	{{ row.source }}	{{ row.confidence }}	{{ row.evidence }}
No timeline events available Paste timestamped incident rows before exporting the ledger.

Phase	Status	First event	Last event	Duration	Events	Handoff	Copy
{{ row.phase }}	{{ row.status }}	{{ row.first }}	{{ row.last }}	{{ row.duration }}	{{ row.events }}	{{ row.handoff }}
No phase handoff rows available Add parsed timeline rows with phases before exporting this table.

Review area	Status	Finding	Next action	Copy
{{ row.area }}	{{ row.status }}	{{ row.finding }}	{{ row.nextAction }}
No quality review rows available Load incident events before exporting the quality review.

{{ markdownReport }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

The hardest part of many incident reviews is not remembering that something happened. It is proving the order in which signals, decisions, mitigations, customer updates, and recovery checks happened. Alerts arrive in one system, responders coordinate in chat or on a bridge, engineers add evidence to tickets, and change records may sit in a separate queue. A timeline turns those fragments into a chronology that other teams can inspect without replaying the whole response.

Chronology is not the same as proof. A clean sequence can make a weak investigation look settled if evidence, confidence, and source context disappear. Good incident notes keep the differences visible: an alert ID, log capture, change record, dashboard snapshot, or ticket comment carries more weight than a memory written hours later, and a suspected cause should not be phrased like a confirmed root cause.

Timestamp: The event time used to place an item in sequence. Time-only notes need a known incident date and a clear time basis.
Phase: The response stage, such as detection, triage, containment, recovery, communication, or review.
Evidence: A stable pointer to the record behind the row, such as an alert, ticket, log capture, dashboard snapshot, bridge note, or change ID.
Confidence: A plain label for how certain the row is. Low-confidence events can stay in the timeline, but they need review before they become findings.

Alerts, chat, logs, tickets, and change records flow into a sorted chronology, phase review, evidence check, and follow-up actions.

Timelines help in several settings: an operations handoff during a long bridge, a post-incident review after service restoration, a security review where containment evidence matters, or a near miss where the team wants to learn without overstating impact. The same discipline applies in each case. Events need to be sorted, quiet periods need to be explained, and important decisions need enough context for someone outside the response channel to understand them later.

The main limit is causality. Sequence can show that a change happened before an alert, or that recovery followed a rollback, but it does not prove why the incident happened. Root cause still needs supporting logs, change records, responder notes, and review decisions that separate confirmed facts from plausible explanations.

How to Use This Tool:

Use one incident record at a time so the ledger, phase handoff, quality review, gap chart, Markdown report, and JSON describe the same event sequence.

Enter Incident ID, Affected service, Severity, Incident date, and Time basis label. The incident date is important when rows use short times such as 08:05.
Write the Impact summary in one or two sentences. Name what degraded, who was affected, and whether the service is still affected or already recovered.
Paste rows into Timeline events, choose Browse CSV, drop a CSV, TSV, or TXT file under 1 MiB, or press Load sample to inspect the expected shape.
Use a header row when possible. A strong source has columns such as time, phase, actor, event, source, confidence, evidence, notes. Shorter rows can parse, but they give the quality review less to check.
Press Normalize rows when pasted notes contain extra blank lines. If Review timeline inputs appears, fix the listed timestamp, delimiter, phase, evidence, root-cause, or follow-up problems before copying the report.
Set Long gap threshold to the cadence expected during active command. A 20-minute threshold flags gaps greater than 20 minutes, not gaps equal to 20 minutes.
Add Root cause and Follow-up actions. Use suspected or pending wording when the cause is not confirmed.
Open Advanced when the report needs a specific Report audience, Default source, or Review owner. Default source text fills blank display fields, but explicit evidence remains stronger for review.
Start with Timeline Ledger to check the sorted events, then use Phase Handoff and Quality Review to decide what needs cleanup before sharing Markdown Report or JSON.

Interpreting Results:

Timeline Ledger is the working chronology. It can differ from paste order because events are sorted by parsed time. If the order looks surprising, check the incident date, time basis label, and any overnight rows before changing the event text.

Phase Handoff shows whether response stages have enough logged events to support a handoff. Detection, Containment, and Recovery are treated as required review phases. Missing communication or review rows may be acceptable, but missing one of the required phases usually means the report cannot yet explain how the incident was found, stopped, and verified.

Long quiet periods points to gaps greater than the selected threshold. Add missing bridge notes or explain why the gap was expected.
Evidence links warns when a row has no explicit source column and no evidence reference.
Confidence posture keeps unconfirmed or suspected rows from reading like settled facts.
Root cause statement and Follow-up actions show whether the report is ready for review, not whether the investigation is complete.

Timeline Gap Chart is useful when a table is too long to scan. The x-axis is elapsed minutes, the y-axis is response phase, and highlighted gaps show where the response record went quiet for longer than the selected threshold.

A clean report should still be checked against the source systems. Verify the first known impact, the mitigation that stopped further harm, the recovery proof, and any row that changes customer impact, security risk, accountability, or follow-up work.

Technical Details:

An incident timeline is a sorted event sequence with review context attached to each row. The timestamp determines order, the phase describes the response stage, the actor names who or what produced the event, and the event text records the observation or action. Source, evidence, notes, and confidence make the sequence auditable instead of turning it into a polished memory.

Time handling is the key technical risk. Full timestamps keep their own date and offset. Time-only rows use the incident date, and overnight rows can roll forward when a later row would otherwise appear more than six hours before the previous parsed row. That keeps a bridge that starts before midnight from looking as if it moved backward.

Formula Core

Elapsed time is measured from the first parsed event. Each gap is measured between adjacent sorted events, then compared with the selected minute threshold.

g_{i} = \max (0, \frac{t_{i} - t_{i - 1}}{60000})

Here t is a parsed event time in milliseconds and g is the displayed gap in minutes. A row is marked as a long gap only when g is greater than Long gap threshold. With a threshold of 20 minutes, 20.0 minutes is not flagged and 20.1 minutes is flagged.

Transformation Core

Incident timeline parsing and review rules
Mechanism	Rule	Review Effect
Row separation	Comma, tab, pipe, and semicolon separated rows are accepted. The first line sets the delimiter used for the paste.	Keep one delimiter style throughout the source to avoid shifted columns.
Header mapping	Recognized headers map time, phase, actor, event, source, confidence, evidence, and notes.	A header row reduces ambiguity when notes come from different tools or teams.
Headerless rows	Rows with three or more cells can still become time, actor, event, and optional source or phase fields.	Headerless input is usable for quick bridge notes, but evidence and confidence are easier to lose.
Phase inference	Explicit phase text wins first. If it is blank or unclear, event wording can infer Impact Started, Detection, Triage, Containment, Recovery, Communication, or Review.	Add the phase yourself when a sentence could describe investigation, mitigation, or recovery.
Evidence test	A row is treated as supported when it has an evidence value or an explicit source column.	Default source text helps display, but ticket IDs, alert IDs, logs, bridge notes, and change records make the review stronger.
Confidence labels	Confirmed, strong, verified, and certain map to High. Suspected, unknown, weak, and unconfirmed map to Low. Blank confidence becomes Medium.	Low-confidence rows should be resolved, corrected, or carried forward as uncertainty.

Quality Rules

Incident timeline quality checks and meanings
Check	Ready Condition	What To Fix
Parsed timeline	At least one usable timestamped event is parsed.	Fix blank timestamps, invalid dates, or shifted delimiters.
Phase coverage	Detection, Containment, and Recovery have logged events.	Add the first alert or report, the mitigation or workaround, and the recovery proof.
Long quiet periods	No adjacent gap is greater than the chosen threshold.	Add missing bridge updates, investigation checkpoints, or a note explaining the quiet period.
Evidence links	Each row has an explicit source or evidence reference.	Attach stable alert, ticket, dashboard, log, bridge note, screenshot, or change references.
Root cause and actions	The root cause field is populated and at least one follow-up action is listed.	Use pending language when cause is not confirmed, and move concrete action items into the owner tracker.

Privacy Notes:

Incident timelines often contain service names, customer impact, internal systems, responder names, alert IDs, change IDs, screenshots, and security details. Treat the generated report as sensitive operational material even when the incident was minor.

Timeline parsing and report generation happen in the browser.
CSV, TSV, and TXT file loading reads local text files under 1 MiB into the browser page.
Copied text, downloaded reports, screenshots, shared browser state, and pasted evidence references can still expose incident details outside the tool.

Worked Examples:

Campus wireless outage

An incident labelled INC-2026-0501 for Campus wireless includes rows from 08:05 through 09:05. The source uses headers for time, phase, actor, event, source, confidence, evidence, and notes. Timeline Ledger sorts seven events, Phase Handoff shows Detection, Containment, and Recovery, and Quality Review stays ready when the alert, CLI capture, change log, and action ID are present.

Threshold edge during a bridge

A SEV2 bridge has events at 14:00, 14:20, and 14:41 with Long gap threshold set to 20. The first gap appears as 20 minutes and is not treated as a long quiet period. The second gap appears as 21 minutes, so Quality Review flags Long quiet periods and Timeline Gap Chart highlights the quiet span.

Overnight recovery

A response starts at 23:50, mitigation is logged at 00:12, and service stability is confirmed at 00:30. With Incident date set to the start date, the later time-only rows roll into the next day and elapsed time increases normally. If Timeline Ledger shows a confusing order, the date and time basis should be checked before editing the event descriptions.

Chat note without a usable time

A pasted line that only says NOC saw controller errors and paged network cannot support the chronology because no timestamp exists. Adding 08:09 as the first cell and splitting the actor from the event allows the row to parse. If Evidence links still warns afterward, add the incident channel, alert ID, or ticket reference before using Markdown Report.

FAQ:

What row formats can I paste?

CSV, TSV, pipe-delimited, and semicolon-delimited rows are accepted. The richest header set is time, phase, actor, event, source, confidence, evidence, and notes.

Why were rows skipped?

Rows are skipped when they have fewer than two cells or the timestamp cannot be parsed. Add a usable time, keep one delimiter style, and set the incident date for time-only rows.

Do I need to type every phase manually?

No. Clear event wording can infer common phases, but explicit phase text is safer when one row could describe triage, containment, or recovery.

Why does the chart show a long gap?

The gap between two adjacent sorted rows is greater than Long gap threshold. Add the missing bridge update or raise the threshold only when your response process allows longer quiet periods.

Are incident notes uploaded for parsing?

Parsing and report generation run in the browser. Downloads, copied reports, screenshots, and shared browser state can still expose incident IDs, service names, sources, and evidence references.

Can the report prove root cause?

No. It organizes the chronology and flags missing evidence, missing phases, long gaps, low-confidence rows, blank root cause text, and missing follow-up actions. Root cause still needs investigation evidence and review decisions.

Glossary:

Incident timeline: A chronological record of observed events, decisions, mitigations, confirmations, and review actions during an incident.
Phase handoff: A response-stage summary showing status, first event, last event, duration, event count, and handoff guidance.
Long gap: A period between adjacent sorted timeline rows that is greater than the selected minute threshold.
Evidence reference: A ticket, alert, log capture, screenshot, bridge note, change record, or other pointer that supports a timeline row.
Confidence posture: The review signal that highlights rows marked with low certainty.
Root cause: The confirmed, suspected, or pending explanation for why the incident happened.
Follow-up actions: A corrective or learning task carried from the incident review into an owner tracker.

References:

NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, National Institute of Standards and Technology, April 2025.
Incident Response, Google Site Reliability Engineering Workbook.
Postmortem Culture: Learning from Failure, Google Site Reliability Engineering Workbook.