Skip to main content
Inspect the event-sourced audit trail the detection engine writes for every check. See Incident Forensics for the conceptual overview.
Every forensic row carries a checkId (the same one minted by the scheduler and stamped on check results) and a policySnapshotHashHex (a content-addressed SHA-256 of the policy that was active). Those two identifiers thread a single detection decision through the whole system.

​
Commands

​
forensics timeline

Renders the incident’s state transitions, the rule evaluations that caused each triggering transition, and the active policy snapshot. Use --output json to pipe the full payload into jq.

​
forensics trace

Shows every evaluation and transition emitted for a single checkId. Useful when a webhook or support ticket references a specific execution ID.

​
forensics snapshot

Fetches the policy JSON that was active at evaluation time. Hashes are stable — an old transition always resolves back to the exact policy that fired it, even if the monitor has since been edited.

​
forensics evaluations

​
forensics transitions

Same pagination flags as evaluations. Each row includes fromStatus → toStatus, reason, the checkId that caused it, and (when the transition was part of an incident lifecycle) the incidentId.

​
Output formats

All forensics commands accept --output table|json|yaml (default table). The rendered table is deliberately terse — for the full DTO use --output json and pipe to jq.

​
Next steps

Incident Forensics

Concepts, retention, and use cases for the forensic model.

Incidents CLI

Pair forensics timeline with incidents get for the full picture.