Audit trail
Changes to your project are recorded with who made them, what they did and when. Team members who hold the permission read the trail in the console.
What an entry holds
An entry names the actor by kind and id (a team member, a service or one of your users), the action, the resource it touched, the time it committed and the id of the request that made it. It records that a change happened. It does not hold the values before and after.
Written with the change
Each entry is written in the same database transaction as the change it describes, so neither can exist without the other. A change that emits no event of its own still gets an entry, named for the action that was called.
Reading it in the console
The Audit log screen sits under Access, with filters for action, resource type, resource id, actor and a date range. Reading it needs the audit:read permission. Of the two ready-made roles, Workspace administrator holds it and Project administrator does not.
The trail covers a project's events and the workspace's own, such as members added and removed. Standing in an organisation, it shows that organisation and those beneath it.
What you will find there
Revoked API keys are recorded, as are a record changing owner, an export that includes password hashes, and changes the AI assistant makes, attributed to the person it acts for. Every support access request, approval and denial is there too.
Kept for 90 days
The event log behind the trail serves a 90-day window on every plan. For a longer history of a project, read the log forward through the Event Log API, with a secret key that holds events:list.project, and store it yourself. A cursor older than 90 days is refused with an error that names where to resume. A public key or a signed-in user's token cannot read the log.
Read the detail
The event log reference covers what an event holds, the 90-day window and reading the log forward into your own store.