Who can see it
Only roles with the Audit logs permission can open the audit log. The permission is read-only: nobody can edit or delete an entry. The Admin role has it by default. To give it to another role, open Settings → Roles, edit the role, and turn on Audit logs.Open the audit log
Go to Settings → Security and scroll to Audit Logs. The newest events are at the top, and more load as you scroll. Each row shows:- Actor — the teammate, API key, Companion, mini-app or automation that acted
- Event — what happened, for example Signed in with Google or Updated workflow
- Target — what it happened to. For sign-ins and sign-outs, this is the teammate and the IP address
- When — how long ago, and the exact time on hover
Filter the log
Combine any of these filters:- Event — all events, only sign-ins and sign-outs, or one area such as Security or Settings
- Actor type — people, the system, or API keys
- Person — one teammate: everything they did, plus the sign-outs the system ended for them
- Date range — one or more whole days
Sign-ins and sign-outs
Every time a teammate signs in, the audit log records how they signed in: Google, Microsoft, single sign-on, partner access or password. It also records their IP address and browser. Every time a teammate stops being signed in, the log records why:
A teammate who belongs to several workspaces shows up in the audit log of each one. Removing a teammate signs them out everywhere: the workspace that removed them sees Removed from the workspace, and their other workspaces see Session revoked. An expired sign-in is recorded the next time that browser opens the dashboard.
Read the log over the API
Use List audit logs to export the trail or feed it into your own security tools. The API key needs theaudit-logs:read scope. The Companion and the MCP get_audit_logs tool read the same log.