The activity timeline
Expand any incident in the dashboard and the timeline shows the complete lifecycle in order, each entry with a state-aware badge, the actor, detail, and timestamp:- Detection - the incident opened, with the symptom
- Analysis - root cause attached, incident
analyzed - Queued - a remediation was created (
proposedor policy-approved) - Approval - who approved: a named human, or
agent-policyunder Auto - Execution - the executor applied the fix
- Verification -
verified, orverify_failedafter the 20-minute window - Rollback (if any) -
rollback_initiated, thenrollback_verified,rollback_failed, orrollback_policy_denied - Resolution or escalation - resolved with attribution, or
escalatedto a human
GET /api/timeline?incident_id=... for export or tooling.
Properties of the record
- Append-only. Events are only ever added, each stamped with actor, timestamp, and detail. Nothing in the product edits or deletes an audit event - state transitions add entries rather than rewriting history.
- Attribution is total. Every execution traces to a named human approval or to
agent-policy, and a policy approval implies the policy’s terms at that moment (namespace, confidence, cap) were satisfied - there is no anonymous path to a cluster write. - Failure is as visible as success.
verify_failed,rollback_failed,rollback_policy_denied, and drift refusals are first-class events. The timeline of an escalated incident shows precisely where automation stopped and why it handed control to you. - Crash-consistent. Controller crash injection during validation confirmed every lifecycle event lands exactly once - no lost events, no duplicates - so the trail remains trustworthy evidence even across control-plane restarts.
Reading a timeline: a failed fix, done right
A healthy escalation reads like this - every hop attributable, terminating with a human:Audit events and timelines are tenant-scoped like all ChangeGuard data. For platform-level authentication and API-access auditing, see Compliance & Audit.