# Audit log

The audit log is your organization's change history: a chronological, read-only record of every management action taken in Bird. When you need to answer "who changed what, and when?" — after a surprise configuration change, during a security review, or while following up on an incident — this is where you look. You'll find it on the [**Audit**](https://bird.com/dashboard/w/logs/audit) tab of the dashboard's **Logs** page: one organization-wide record, viewable from any of your workspaces, with a filter to narrow it to a single workspace.

![The audit log in the Bird dashboard: a table of management actions — Created API key, Created suppression, Rotated webhook secret, Created organization dedicated IP, Created inbound address — each with its time, the actor's email, the workspace it applied to, and a green Succeeded outcome badge, above search and filter controls and an OCSF export button](/images/docs/dashboard-logs-audit.png)

## What gets recorded

The audit log captures management changes — actions that change how your account is set up, not the messages you send. That includes:

- **API keys** — creation and revocation
- **Sending domains** — adding, verifying, and deleting domains
- **Webhooks** — creating, updating, and deleting endpoints, and rotating signing secrets
- **Workspaces and organization** — creating, renaming, and deleting workspaces; organization setting changes
- **Team** — invitations, role changes, and member removals
- **Security events** — logins (including failed attempts), MFA changes, recovery-code regeneration, and password resets
- **Billing actions** — changes made through your billing settings

Day-to-day traffic is deliberately not in the audit log: individual emails sent, delivery and open events, and read-only views of pages don't generate entries. Those live in your messaging logs and analytics instead.

## Reading an entry

Every entry answers the same three questions:

- **Actor — who.** The user who clicked, or the API key that made the call. Actions taken by Bird's own systems are marked as such.
- **Action — what.** A short name like `api_key.created`, `domain.verified`, or `member.role_updated`: the resource that changed and what happened to it.
- **Timestamp — when.** The exact time the change happened.

Entries also carry context — the target resource, the IP address and client the request came from, and a request ID — so you can tie an entry back to a specific machine or support case. Sensitive values such as key secrets never appear in entries.

## Using it in practice

- **"Why did sending break on Tuesday?"** Filter to that day and look for domain, webhook, or API key changes just before the breakage.
- **Security review.** Skim security events for failed logins you don't recognize, MFA factors being removed, or API keys created outside normal change windows.
- **Offboarding check.** After someone leaves, confirm their member removal is recorded and review what they changed in their final weeks.
- **Incident follow-up.** The actor, IP, and request ID on each entry give you a concrete trail to include in an incident write-up.

## Who can see it

Audit log access is an organization-level permission, typically held by organization admins and owners. Members without it won't see the page. Entries cannot be edited or deleted by anyone — including admins — which is what makes the log trustworthy as a record.

## Next steps

- [API key management](/docs/knowledge-base/account-security/api-keys) — the key events you'll see most often
- [Login, password & MFA](/docs/knowledge-base/account-security/login-mfa) — the security events behind the log entries