# Read the audit log

Every Koo account keeps an audit log: an append-only record of who did what, and when. Open **Audit** in your account to read it — any member can, whatever their role. Nothing ever edits or removes an entry.

The log is the accountability half of Koo's permission model. [Roles](/docs/collaboration/teams-and-roles) decide who may act; the audit log records that they did. That is why a reader may reveal a sensitive value: the reveal isn't blocked — it's recorded.

## What gets recorded

- 
- 
- 
-

Reveals are recorded fail-closed: the audit entry is written before the value is returned, so a reveal that can't be recorded doesn't happen.

## Read an entry

Each row names the actor, the action, its target, and when it happened. The actor is the member's email or handle; an action performed with an API token shows as **API token**, and one performed by Koo itself shows as **system**.

Click a row to expand it. The detail shows where the action landed — project, environment, and service — and a field-level before-and-after diff of what changed, when the event captured one.

Two badges qualify a row. An action that didn't succeed carries its status — **error**, **blocked**, or **pending** — and an action taken by Koo support on your behalf carries **via support**.

The log lists newest first. **Load more** walks further back.

> **Note:**
>
> The audit log is the request trail: it records what was asked for. Deploy outcomes — build and rollout results — live on each service's Deployments tab; see [deployments & rollback](/docs/deploy/deployments-and-rollback).

## Read it programmatically

The same feed is served by the [accounts API](/api/accounts), newest first, authenticated with an [API token](/docs/developers/api-tokens) of either role:

```bash
curl "https://api.koo.io/accounts/{accountId}/events" \
  -H "Authorization: Bearer kc_…"
```

Each page carries an opaque `page.nextCursor`; pass it back as `cursor` to read older entries.