Worked timeline row
In the fictional case, an API request is seen at 10:00 UTC and a provider success event at 10:01. A ledger import fails at 10:03. The timeline should record both event and observed time for the provider message, the provider reference, the failed import ID, and a link to the preserved log. The sentence “ledger import caused the missing balance” is a hypothesis until the import record and ledger query confirm it. The downloadable row is marked FICTIONAL_EXAMPLE to prevent it from being used as a real incident claim.
Build the timeline from records
Start with an agreed UTC clock. Pull request logs, provider events, queue retries, ledger commits, and customer messages. Keep event time and ingestion time in separate columns because delayed messages can look out of order.
Checks to run
- Record event time, observed time, source, exact ID, status, and evidence link for each row.
- Mark unknown facts as unknown. Keep hypotheses in a separate column from confirmed facts.
- Note containment, customer impact, owner, recovery action, and the point when reconciliation closed.
Template columns
The file separates event time from observed time and confirmed fact from hypothesis. This prevents a late provider callback from appearing to precede a payment simply because the systems used different clocks. Put the exact source ID in the evidence column.
All eight example rows are marked FICTIONAL_EXAMPLE. Delete them for a real incident. Do not copy real customer details into a public timeline. Preserve the raw evidence in a restricted system and share a redacted timeline with the review team.
Join four records
Use the fictional incident file to line up the API request at 10:00, provider success at 10:01, failed ledger job at 10:03, and successful credit at 10:04 UTC. Convert every time to UTC and keep the source zone in original_time_zone and the raw timestamp in the restricted evidence record. Join by operation ID and provider reference, not by matching the amount alone. The redelivery at 10:05 retains the original provider event time of 10:01. Keep both clocks to explain the delay. Mark missing events as unknown and name the system expected to produce them. NIST’s audit and incident-control catalog supports keeping event and response records.
For timeline revision 1.1, check the linked field guide before replacing fictional rows; it defines event time, observed time, missing facts, and private evidence links. field guide and calculation rules.
Keep clock uncertainty in the evidence
Sort the timeline by event time for display, but do not infer cause from that order alone. In a synthetic test, the provider clock is 45 seconds ahead while the queue clock is correct. Use original_time_zone for the source zone and clock_offset_ms for known offset; preserve the raw timestamp in the source record referenced by evidence_uri. Mark uncertain ordering in hypothesis until source IDs and request links establish it. A later observed_time_utc can explain redelivery without changing the original event time. Confirm closure from the reconciled ledger and provider records, not from the last timestamp. Keep missing events explicit.
Primary sources
Download fictional timeline and blank row.
Next step
Copy the blank timeline row into a private incident record and link the first confirmed event to its raw source. Read the related guide. For a review of your own system, request a security review.