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 in the dashboard under your organization's settings, with a per-workspace view under the workspace's Logs section.
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.
Related
- API key management — the key events you'll see most often
- Login, password & MFA — the security events behind the log entries