{{ summaryHeading }}
{{ primaryFigure }}
{{ summaryLine }}
{{ badge.label }}
Use the ticket, bridge, PIR, or case identifier.
Keep it short enough to scan in report titles and export filenames.
Choose the incident severity used by your response process.
Required for time-only timeline rows; full ISO timestamps keep their own date and offset.
State what was degraded, who was affected, and the current status.
Paste incident notes as CSV, TSV, pipe, or semicolon rows; parsing stays in this browser.
{{ events.length.toLocaleString() }} chars
{{ fileStatus || 'Drop CSV or TXT onto the textarea.' }}
Add the best current cause statement; keep unknowns explicit.
Use concrete actions that belong in the post-incident review or action tracker.
Pick the review context for the generated report wording.
Use the response cadence expected during active incident command.
min
This labels the report; ISO timestamps with offsets keep their parsed instant.
Use a bridge log, incident channel, ticket system, or runbook note label.
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 }}
PhaseStatusFirst eventLast eventDurationEventsHandoffCopy
{{ row.phase }} {{ row.status }} {{ row.first }} {{ row.last }} {{ row.duration }} {{ row.events }} {{ row.handoff }}
Review areaStatusFindingNext actionCopy
{{ row.area }} {{ row.status }} {{ row.finding }} {{ row.nextAction }} 
{{ markdownReport }}

        

      

    

  

                

                

                    

                        

                            Tags:
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
Incident timelines are chronological records of what was observed, decided, changed, and confirmed during a service disruption, security event, or near miss. A useful timeline connects alerts, responders, mitigation steps, recovery checks, communication updates, and follow-up actions to specific times so the review can separate fact from memory.


    
Good timelines matter because incident notes usually arrive from several places at once: bridge chat, monitoring alerts, ticket comments, command output, status updates, and change logs. Sorting those fragments by time makes it easier to see when impact began, how quickly responders detected the problem, when containment happened, and whether recovery was confirmed before the incident was closed.


    
An incident timeline is not the same as proof of root cause. A row can describe a suspected cause, an unverified observation, or a confirmed fix, and those should not be treated the same way. Evidence references, source labels, and confidence wording protect the report from sounding more certain than the response team actually was.


    
The strongest post-incident record is short enough to scan and detailed enough to audit. It shows the order of events, calls out quiet periods that need explanation, preserves uncertainty, and carries corrective actions into the next owner review.

  






  

    
Technical Details:


    
An incident timeline row has three minimum facts: when the event happened, who or what reported it, and what changed or was observed. Additional fields such as phase, source, confidence, evidence, and notes make the record easier to defend later because they say whether the row came from monitoring, a responder, a ticket, a log reference, or a review decision.


    
Chronology is the first mechanism. Full timestamps can carry their own date and offset. Time-only rows need an incident date so the clock values can be placed on a real day, and overnight rows may need to roll forward when a later row would otherwise appear many hours before the previous one. After timestamps are parsed, rows can be sorted by actual time while retaining enough source detail to explain the original note.


    

      Incident event rows move into parsed times, inferred phases, a sorted ledger, quality checks, a gap chart, Markdown, and JSON handoff output.
    


    
Rule Core

    

      

        
        
          

            Rule
            How it is derived
            How to read it
          

        
        
          

            Row shape
            Preferred rows use time, phase, actor, event, source, confidence, evidence, and notes. Shorter legacy rows can still provide time, actor, and event.
            Rows with fewer than two cells or unusable timestamps are skipped and reported as parser warnings.
          

          

            Delimiter detection
            The first row is checked for comma, tab, pipe, and semicolon separation, including quoted cells.
            Use one delimiter consistently. Mixed delimiters can make important cells land in the wrong column.
          

          

            Timestamp handling
            Full timestamps are parsed directly. Time-only rows use the incident date, with overnight rollover when sequence timing would otherwise move far backward.
            Set the incident date before using time-only entries such as 08:05 or 11:40 PM.
          

          

            Phase assignment
            Explicit phase text is used when it matches known response terms. Otherwise, event wording is matched to Impact Started, Detection, Triage, Containment, Recovery, Communication, or Review.
            Write clear phase names when the event wording could be ambiguous, especially for containment and recovery.
          

          

            Long gaps
            Each row is compared with the previous sorted row. A gap greater than the configured minute threshold is flagged.
            A long gap is not always a fault, but it should be explained with bridge notes, investigation updates, or status messages when the incident was active.
          

          

            Quality review
            Parsing status, required phase coverage, long gaps, evidence references, low-confidence rows, root cause text, and follow-up actions are checked.
            Review findings point to report cleanup work. They do not independently verify whether the incident was solved.
          

        
      

    


    

      

        
        
          

            Result surface
            What it contains
            Best use
          

        
        
          

            Timeline Ledger
            Sorted events with formatted time, elapsed time, gap, phase, actor, event, source, confidence, and evidence status.
            Use it as the primary chronology before copying rows into a review note.
          

          

            Phase Handoff
            Phase coverage, first and last event times, duration, event counts, and handoff guidance for each response phase.
            Find missing Detection, Containment, or Recovery evidence before sharing a report.
          

          

            Quality Review
            Review areas with Ready, Review, Issue, or Note style statuses, findings, and next actions.
            Decide what must be fixed before a post-incident review or operations handoff.
          

          

            Timeline Gap Chart
            Event sequence plotted by elapsed minutes and response phase, with long gaps highlighted.
            Spot quiet periods and sequence jumps faster than scanning a long table.
          

          

            Markdown Report and JSON
            A narrative handoff report and a structured payload containing incident details, events, phase handoff rows, quality review rows, warnings, and errors.
            Move the same reviewed evidence into a post-incident document, ticket, or automation step.
          

        
      

    

  






  

    
Everyday Use & Decision Guide:


    
Start with the incident header fields before pasting rows. Incident ID, Affected service, Severity, and Incident date give the report enough context to make copied tables and handoff text recognizable later. Add a short Impact summary that says who was affected, what was degraded, and whether service has recovered.


    
For timeline rows, the most reliable first pass is a small table with headers: time, phase, actor, event, source, confidence, evidence, notes. If all you have is a rough bridge note, use at least time, actor, and event. Add the source or evidence reference before final review so the output does not turn a memory-based note into a confident-sounding finding.


    
    
      
  • Use Load sample to see the expected shape before replacing it with the real incident.
    • 
      
  • Use Browse CSV or drag a supported text file when the timeline already lives in a spreadsheet export.
    • 
      
  • Click Normalize rows after a chat paste with blank lines or uneven spacing.
    • 
      
  • Set Long gap threshold to the response cadence your team expects during active command, such as 15, 20, or 30 minutes.
    • 
      
  • Set Report audience to Operations handoff, Post-incident review, Executive brief, or Security review so the final handoff note uses the right emphasis.
    • 
    


    
Do not treat Incident Timeline Ready as a sign that the investigation is complete. It means the parsed record has no blocking review findings under the current inputs. Confirm the root cause statement, evidence references, low-confidence rows, and follow-up actions before copying the Markdown report.


    
When the result says Timeline Needs Evidence, open Quality Review first. Missing sources, low-confidence rows, blank root cause text, or missing follow-up actions are usually faster to fix there than by rereading the whole timeline.

  






  

    
Step-by-Step Guide:


    
Follow this path when raw incident notes need to become a shareable handoff record.


    
    
      
  1. Enter Incident ID, Affected service, Severity, and Incident date. The summary should move away from Incident Timeline Needs Input once usable event rows are present.
    2. 
      
  2. Write the Impact summary in one or two sentences. Keep affected users, degraded function, and current status in the same paragraph so the Markdown report opens with clear impact.
    3. 
      
  3. Paste rows into Timeline events, use Browse CSV, or drag a CSV, TSV, or TXT file under 1 MiB onto the textarea. If the warning panel says no usable timeline events were found, fix the timestamp column or row delimiter before reading results.
    4. 
      
  4. Click Normalize rows if the paste has blank lines or inconsistent spacing. The helper text should confirm that row spacing was normalized or that a file was loaded.
    5. 
      
  5. Add Root cause and Follow-up actions. Use suspected, known, or pending wording when the cause is not fully proven, and put each follow-up action on its own line.
    6. 
      
  6. Open Advanced when the report needs a specific Report audience, Long gap threshold, Time basis label, Default source, or Review owner.
    7. 
      
  7. Check the summary badges for event count, phase count, long gaps, and evidence gaps. Resolve any Review timeline inputs messages before using the report as a handoff artifact.
    8. 
      
  8. Read Timeline Ledger, then Phase Handoff and Quality Review. Use Timeline Gap Chart when quiet periods need visual review, and use Markdown Report or JSON only after the evidence checks make sense.
    9. 
    


    
A clean run ends with a sorted ledger, phase coverage for the required response stages, no unexplained evidence gaps, and follow-up actions ready for an owner tracker.

  






  

    
Interpreting Results:


    
Timeline Ledger is the primary record. It shows the sorted sequence, not necessarily the original paste order. If the input order was different, trust the parsed times first, then compare against the source notes to make sure the timestamp meaning was not reversed by an incorrect incident date or time basis label.


    
Phase Handoff is strongest when Detection, Containment, and Recovery are present and supported by evidence. Missing optional phases can be acceptable, but missing required phases usually means the review cannot yet explain how the team found the issue, stopped the damage, and confirmed service restoration.


    
    
      
  • Long quiet periods means at least one gap is greater than the selected minute threshold. Explain the gap or lower confidence in the timeline.
    • 
      
  • Evidence links warns when rows have no source column and no evidence reference. Add ticket IDs, log references, screenshots, or bridge-note links.
    • 
      
  • Confidence posture warns when a row is marked Low. Keep the uncertainty visible until the row is confirmed or removed.
    • 
      
  • Root cause statement and Follow-up actions turn the timeline into a review artifact, but they should not hide uncertainty.
    • 
    


    
A tidy quality table does not prove the incident was fully understood. It only means the report has enough structure to review. Before sharing, verify the earliest impact time, the recovery confirmation, and any row that changes blame, risk, customer impact, or corrective action.

  






  

    
Worked Examples:


    
Campus wireless outage after switch maintenance

    
An incident with Incident ID set to INC-2026-0501, Affected service set to Campus wireless, and Incident date set to 2026-05-01 includes rows from 08:05 through 09:05. The parser sorts 7 event rows and the summary shows a duration of about 1 hour, 6 phases, no long gaps above the default 20-minute threshold, and no evidence gaps when source or evidence values are present.

    
Timeline Ledger shows AP disconnect alerts first, VLAN mismatch discovery during containment, AP recovery, and a review follow-up. Phase Handoff confirms Detection, Containment, and Recovery, while Quality Review treats the root cause and follow-up lines as populated. That is a good handoff shape, provided the referenced alert, change log, and action item IDs are real.


    
Overnight bridge with time-only rows

    
A bridge starts at 23:50 on 2026-05-01, mitigation is logged at 00:12, and recovery is confirmed at 00:30. With Incident date set to 2026-05-01, the later time-only rows roll into the next day instead of being sorted before the first row. Timeline Ledger then shows elapsed time increasing from start to recovery.

    
If the Timeline Gap Chart looks wrong for an overnight incident, check Incident date and Time basis label before changing the event text. A wrong date can make a valid response look out of order.


    
Chat notes that fail to become a report

    
A pasted chat transcript that says NOC saw errors and paged network without a timestamp can trigger No usable timeline events were found. Add a first cell such as 08:09 and split the row into actor and event fields, or paste a small CSV with time,actor,event headers.

    
Once rows parse, Quality Review may still warn about Evidence links because the transcript does not name a source or evidence reference. Add a ticket ID, alert ID, bridge note link, or log capture before copying Markdown Report.

  






  

    
FAQ:


    

      What row formats can I paste?
      
Use CSV, TSV, pipe-delimited, or semicolon-delimited rows. The preferred headers are time, phase, actor, event, source, confidence, evidence, and notes, but shorter time, actor, and event rows can still parse.

    


    

      Why were some rows skipped?
      
Rows are skipped when they have too few cells or the time value cannot be parsed. Add a usable timestamp, keep one delimiter style, and set the incident date when using time-only rows.

    


    

      Does the phase have to be typed exactly?
      
No. Clear phase text is used when present, and event wording can infer phases such as Detection, Containment, Recovery, Communication, and Review. Type the phase explicitly when wording could fit more than one response stage.

    


    

      Why does a long gap appear?
      
A long gap appears when the time between adjacent sorted rows is greater than Long gap threshold. Raise the threshold only if your response process allows longer quiet periods during active incident command.

    


    

      Are incident notes uploaded for parsing?
      
Parsing and report generation run in the browser for this tool. Copied reports, downloaded files, screenshots, and shared browser state can still expose incident IDs, services, sources, and evidence references.

    


    

      Can this prove root cause?
      
No. It organizes the chronology and flags missing evidence, confidence, phase, and follow-up gaps. Root cause still needs confirmation from logs, changes, responder notes, and review decisions.

    

  






  

    
Glossary:

    

      
Incident timeline

      
A chronological record of observed events, decisions, changes, and confirmations during an incident.

      
Phase

      
A response stage such as Detection, Triage, Containment, Recovery, Communication, or Review.

      
Long gap

      
A period between adjacent timeline rows that is greater than the configured minute threshold.

      
Evidence reference

      
A ticket, alert, log capture, screenshot, bridge note, or other pointer that supports a timeline row.

      
Confidence

      
The certainty label attached to a row, commonly High, Medium, or Low.

      
Phase handoff

      
A phase-by-phase summary showing status, first event, last event, duration, event count, and handoff guidance.

      
Quality review

      
A set of checks that flags parser issues, required phase gaps, long quiet periods, evidence gaps, low-confidence rows, missing root cause text, and missing follow-up actions.

    

  






  

    
References: