---
title: Audit log
description: Read the workspace audit log, know exactly which administrative events it records, and know the two things it deliberately does not cover.
updated: 2026-08-05
tier: pro
---

Every workspace keeps a log of administrative changes, readable by its admins.

Open **Settings**, switch into the workspace, open its **Security** section, and
scroll to **Audit log**. The panel describes itself accurately:

> Administrative changes in this workspace, newest first. Visible to admins only.

It loads the most recent events and pages backwards with **Load older events**.

## What is recorded

| Area | Events |
|---|---|
| The workspace | created, renamed |
| Membership | invited, role changed, removed, left |
| Directory sync | provisioned by SCIM, deprovisioned by SCIM |
| Domain | verified, released |
| Dashboards | transferred into the workspace |
| Teams | created, updated, visibility changed, deleted, and members joining, being added, leaving, or being removed |

Entries read as sentences naming the actor and the target, for example
"Jo invited sam@acme.com as member" or "Jo verified acme.com".

SCIM entries have no human actor, because the change came from your directory
rather than from a person clicking something. They name the affected person
only.

## The log cannot be edited

Audit rows are append-only **in the database itself**, not merely in the user
interface. Updates, deletes, and table truncation are all rejected at the storage
layer, so no amount of application-level access can rewrite history in place. A
mistaken entry stays and is corrected by the next entry rather than by editing
the last one.

## What it does not cover

Three gaps, all worth knowing before you rely on this for a control.

**It is not a dashboard change log.** Publishing, updating, renaming, changing
visibility, and deleting a dashboard are recorded somewhere else: the
**Activity** page in the main app. That feed is scoped to the dashboards **you**
created, which means **a workspace admin cannot see other members' dashboard
activity** through it. There is no workspace-wide view of who changed which
dashboard.

**It is not a data-access log.** Who opened a published dashboard, and which
queries ran against your warehouse, are not in here. Refresh runs and their
outcomes are in the Schedules page's run history instead. See
[Schedules](/concepts/schedules).

:::warning{title="Administrative entries are best-effort, so a missing entry proves nothing"}
Audit writes for administrative actions happen in the background and are
deliberately allowed to fail without failing the action itself. An invite that
cannot be logged is still an invite.

The consequence for you: **the presence of an entry is evidence the thing
happened; the absence of an entry is not evidence it did not.** If you are
reconciling an incident, confirm against the member list and the workspace's
current state rather than treating the log as complete.

Team events are the exception. Those are written in the same transaction as the
change, so they are all-or-nothing.
:::

## Retention

There is no retention window and no purge: entries stay for the life of the
workspace.

The corollary is the part that matters. **Deleting a workspace deletes its audit
log with it**, permanently and immediately. If you need the record of a workspace
you are winding down, read it and keep a copy before you delete it, because there
is no export and no recovery afterwards.

Deleting a *person's* account leaves the entries in place. The rows survive with
the names they were written with, so removing someone does not blank the history
of what they did.

## Other logs you may be looking for

- **Your own dashboard changes**: the **Activity** page in the app. Publishes,
  updates, renames, visibility changes, and deletes, for dashboards you created.
- **Your AI tool's connections**: **Settings**, then **MCP**, which lists recent
  authorizations of the publishing connection against your account.
- **Refresh outcomes**: the **Schedules** page's run history. See
  [Set a refresh schedule](/guides/refresh-schedule).

## Check it worked

You cannot turn the audit log on or off, so the check here is that you can read
it and that it is current.

1. **Do something small and find it.** Invite yourself to nothing, or simply
   rename the workspace to the same name with a trailing character and back. A
   real administrative change should appear at the top of the log within a
   reload.
2. **Confirm your colleagues cannot read it.** Ask a member, not an admin, to
   open the workspace's Security section. They should see "You are not an admin
   here" rather than the log.
3. **Before deleting any workspace, read the log first.** Deletion removes it
   with no export. This is the only irreversible thing on this page.