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 notifynodata 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.

The Datadog audit trail docs cover the event stream of organization changes (who did what, when). Verified against live docs 2026-09-26.