Audit trail: incident review starts with who changed what

# Audit trail for change accountability

## What it gives you

The audit trail records org-level changes: who created, modified, or deleted monitors, dashboards, SLOs, keys, and settings, and when. It is the answer to "who changed this monitor last Tuesday."

## Build the habit

1. **Incident review starts here.** Before theorizing about why the monitor did not fire, check the audit trail: was the threshold changed, was the monitor muted, was notify_no_data flipped.
2. **Key lifecycle**: audit who created API and application keys and when. Stale keys from departed team members get revoked on a schedule, not discovered in a breach.
3. **Pair with Terraform.** When monitors are code, the audit trail should show applies from the CI identity, not humans. A human editing a Terraform-managed monitor in the UI is the anomaly to investigate.
4. **Access reviews**: periodic review of who has admin, who can edit monitors, who can manage keys. The audit trail shows whether the permissions match the policy.

## Limits

The trail is an event stream, not a backup: it tells you what changed, not the previous value. For real rollback you need the Terraform state or dashboard JSON in git. Treat audit as detection, version control as recovery.

## Verify

Change a monitor in staging, find the change in the audit trail with the right actor and timestamp. If you cannot find your own change, the trail is not configured or not retained long enough for your compliance needs.