---
title: Audit log
description: A record of who changed what in your workspace.
sidebar:
  label: Audit log
---

{/* Source of truth: packages/shared/src/audit-logs.ts — 80+ action types
    across 16 resource types. Permission: VIEW_AUDIT_LOG.
    Plan gate: auditLog in plans.ts (Business). */}

The audit log records administrative actions across the workspace — who did it,
what changed, and when.

:::note
The audit log is available on the **Business** plan, and requires the
`VIEW_AUDIT_LOG` permission (owners and admins). See
[Plans and limits](/billing/plans) and
[Members and roles](/organization/members-and-roles).
:::

## What is recorded

Over 80 action types across 16 kinds of resource, including:

- **Monitors** — created, updated, deleted, paused, resumed, acknowledged
- **Notification channels** — created, updated, enabled, disabled, deleted
- **Status pages** — created, updated, published, unpublished
- **Custom domains** — the full lifecycle: registered, verified, certificate
  issuing, activated, failed, removed
- **Incidents and postmortems** — created, updated, published, resolved
- **Members** — invited, joined, role changed, removed
- **API keys** — created, rotated, revoked, deleted
- **Workspace and billing** — settings and subscription changes

## What it is good for

- **Explaining a change nobody remembers making.** "Why did this monitor stop
  alerting?" is usually answered in one query.
- **Access reviews.** Who has been added, and with what role.
- **Incident timelines.** Correlating a config change with the outage that
  followed it is often the fastest root cause you will get.
- **Compliance evidence** for auditors who want to see change control.

## Reading it well

Filter by resource when you are investigating something specific, and by actor
when you are reviewing access. When correlating with an incident, line the audit
timestamps up against the monitor's
[heartbeat history](/monitors/reports) — a config change immediately before the
first failure is rarely a coincidence.