Organize an incident timeline without jumping to a root cause

A useful incident timeline preserves the sequence and quality of evidence. The assistant should not turn the first plausible explanation into a proven root cause.

Prepare the input

Supply sanitized observations, relevant log extracts, action records, and time-zone information. Keep original timestamps. If clocks differ or an event time is inferred, state that explicitly.

Run the workflow

Request a timeline with observation, source, action, and uncertainty. Put hypotheses in a separate section. A recovery after a change may be relevant evidence, but it does not by itself prove causation.

Prompt to copy

Build an incident timeline from: [sanitized evidence].
Keep timestamp, time zone, source, observation, action, and uncertainty.
Separate confirmed facts from hypotheses and missing evidence.
Do not invent logs or claim causation from sequence alone.
List the next evidence checks that would distinguish the hypotheses.
Do not execute commands or change infrastructure.

Review a worked example

Illustrative records show an error at 10:02, a restart at 10:05, and healthy responses at 10:07. The timeline can report recovery after restart. It cannot conclude that memory exhaustion caused the issue without evidence. Check time zones and distinguish event time from the time a person wrote the note.

Keep simultaneous events separate when ordering is uncertain. A neat timeline should not imply a precision the evidence lacks. Note whether a source is a machine timestamp, an operator observation, or a later recollection. Those differences help the reviewer decide which hypothesis deserves the next investigation step.

Use it again

Have the incident owner add verified findings. Retain unresolved questions rather than polishing them away. Bot can support evidence preparation; operational access and changes require a separate authorized scope.