What you came for
There is a question every product owner eventually gets asked, sometimes by a customer, sometimes by an auditor, sometimes by their own engineering lead at 8 a.m. "Who changed that, and when?" The audit log is the answer. It is the workspace-wide ledger of every privileged action — every member added, every token minted, every integration connected, every routine reassigned, every repo onboarded — with the actor, the time, the target, and the payload of what changed.
You will find it on the Audit page. It is owner- and admin-visible by default. Other roles see a polite no access message rather than a partial view.
What gets recorded
The log captures the things that matter for compliance and the things that matter for debugging "why is the system doing that this morning?" Both audiences read the same page.
The reference workspace's log shows a steady stream of actions. Some are routine — a routine claiming a schedule window, a pipeline run completing. Others are human decisions you would want a record of — someone promoting a member, someone connecting a tracker, someone rotating an API token. Action names are deliberately short and grep-friendly. REPOSITORY_RUN_CLAIM when a routine takes ownership of a scheduled run. MEMBERSHIP_DEFAULTED when a workspace assigns a default role. AGENT_REASSIGNMENT_QUEUED when an agent's job is moved between specialists. GROUP_MEMBERSHIP_VOL_QUEUE when a bulk membership change is processed. The names are not glamorous on purpose — they are easy to search for in a year, when nobody remembers what the screen looked like.
How the filters work
The page header has a row of chips, and a small form below for the deeper filters. Together they let you carve fifty rows out of fifty thousand without scrolling.
- Category chips. Across the top: All, Workspace, Members, Auth & tokens, Integrations, Artifact repos, Pipelines, Repos, Improvements, Clarifications, Invites, Agent. Each chip narrows the log to one family of action. Members covers invites, role changes, removals. Auth & tokens covers PATs and integration credentials. The categories match the way your security team will ask questions — "show me everything that happened to members last week" — so the answer is one chip away.
- Actor. A substring search over the email of the person, or the name of the token, that did the action. Type alex@ and you get every move by Alex. Type ci-bot and you get every move by the named automation.
- Target kind. A dropdown of what was acted on — workspace, user, API token, integration, artifact repo, pipeline, pipeline run, workspace repo, invite, improvement. "Show me everything that ever touched this integration" — pick the target kind, scroll the result.
- Since / Until. Plain ISO dates. "Between the 1st and the 10th."
The filters compose. You can ask "every action by Alex against integrations in the last seven days" and the log will give it to you, paginated, in order, with a stable cursor for the next fifty rows.
How to read a row
Each row tells one self-contained story. The actor, the action, the target, the time. Click the row to expand the payload and see the structured before / after of what changed — the old role next to the new role, the old token name next to the new one, the integration ID and its scopes.
The payload matters. It is the difference between "a token was minted" (which a log would tell you) and "a token was minted by alex@example.com on 2026-05-12 with scope read-workspace, named ci-prod-deploy" (which is what you actually need when something later goes wrong). Audit answers questions that future tense will ask.
Pagination that preserves your search
Hitting Older → at the bottom of the log does not widen your filter. Every active filter — chips, actor, target kind, dates — gets carried into the next page automatically. You can walk backwards through six months of one filtered view without ever losing the question you started with. This sounds like a small thing. It is the difference between using audit as a real investigative tool and treating it as an unsearchable wall of text.
Export
For longer questions and for handing data to a regulator, the log exports cleanly. The same filters apply. The export is the same data as the on-screen rows, with one row per action and the payload as a structured field your auditor can parse.
When to read the log
Three habits cover most use of audit:
- Weekly sanity check. Once a week, set Since to seven days ago and scroll. Familiarise yourself with normal. Next time something feels off, you will notice.
- After an incident. The first place to look is not the dashboards — it is the audit log. Set Since to before the incident, read what changed. Most "mysterious" incidents stop being mysterious when you see the configuration change someone made forty minutes earlier.
- When a question lands. "Did we rotate that token?" "Who added this integration?" The log answers in seconds, always faster than asking around.
Audit logs are dull in the same way fire alarms are dull. The promise is that on the day a question lands you cannot afford to be wrong about, the answer is already on this page.