Skip to main content
The audit log records every change made through the API or the dashboard: who did it, what they did, what it touched, and from where. Use it to answer “who deleted that key?” or to show a compliance reviewer. Entries are written automatically, and nobody can edit or delete them.

​
What an entry contains

Each entry has:
  • An event, such as key.create or portal.session.exchange. See Audit log event types.
  • An actor, with a type, ID, and name. The type is user (someone in the dashboard or signed in to the CLI), rootkey (an API call), portalEndUser (one of your customers in a developer portal), github (a push or pull request on a connected repository), or system (Unkey itself). Actions taken through the CLI are recorded as user, with via: "cli", the session ID, and the device name in the actor metadata. The dashboard doesn’t show actor metadata, but log drains include it as actor.metadata.
  • The resources it touched, each with a type, ID, name, and optional details such as the fields that changed.
  • The caller’s IP address and user agent, and a readable description.
  • A correlation ID that groups entries from one action, such as a key creation and the permissions it attached.
Every entry you can see is in the unkey_mutations bucket, the only option in the dashboard’s Bucket filter.

​
Which actions are logged

Creates, updates, and deletes are logged for keyspaces, keys, root keys, identities, roles, permissions, rate limit namespaces and overrides, portals, log drains, every Compute resource, and workspace settings. Team membership changes aren’t logged. Most reads aren’t logged. The exceptions are key.verify when a root key calls keys.verifyKey, ratelimit.limit when a root key calls ratelimit.limit or ratelimit.multiLimit, and secret.decrypt when someone reveals a one-time share link. Verifications by the gateway or a portal session aren’t in the audit log. They’re in analytics. Root-key requests blocked by an IP allowlist also emit auth.ipDenied. These events include the attempted source IP in remote_ip and the allowlist in meta. Delivery is best-effort and does not use the MySQL outbox.

​
Reading the log

Open Audit log in the dashboard sidebar. Entries are newest first. Expand one to see its resources, description, IP address, and user agent. Filter by Events, Users, Root Keys, Bucket, and time range. Press F to open the filters and Q to reopen saved filters. Every workspace role can read the log, including viewers, but only admins see keys in the Root Keys filter.
Audit log page listing events with time, actor, action, and event, with one entry open showing its description, actor, and details

​
Retention

Your plan sets how long entries are kept. Check the Audit log retention row on Settings > Limits. A paid API tier sets retention whatever Compute plan you hold. The Compute rows apply only without a paid API tier. See Limits. No plan keeps audit logs longer than 90 days. To keep them longer, or in your own systems, stream them out with a log drain.
Last modified on November 6, 2026