Audit log
The append-only record of configuration changes — what it captures, how to read it, and what it deliberately does not cover.
Audit is an append-only trail of every configuration change in your organization. Org admins only; a member who navigates here directly gets an "org admins only" page, because the underlying endpoint refuses them too.
What each row holds
| Column | Contents |
|---|---|
| Time | Relative ("2 hours ago"), with the exact timestamp on the row |
| Actor | The email of whoever made the change |
| Action | A dotted action name, humanized — playbook.update reads as Playbook · Update |
| Target | What was changed |
Expanding a row shows the full detail, including before/after payloads. That is the part that answers "who changed the spend cap and what was it before?" — the list view only tells you that someone did.
The action vocabulary
Actions are dotted strings that grow over time. Today's portal-side set covers:
| Prefix | Covers |
|---|---|
org.* | Organization settings — the spend cap, default connectors |
playbook.* | Playbook create, update, disable, delete |
mcp.* | Shared integration create, update, delete |
llm.* | AI provider create, update, delete |
Actions are humanized from the string itself rather than looked up in a fixed table, so a newly added action shows up readably instead of rendering blank.
The desktop side writes its own entries for things that happen there — including
issue.create when an issue is filed to GitHub or GitLab, and issue-tracker
connect/disconnect.
Paging
50 rows per page, newest first, with Load more to continue. Paging is cursor-based rather than offset-based, so rows written while you are reading do not shuffle the page under you.
There is no action filter in the portal. Searching the trail systematically means paging through it here and filtering the rows yourself.
Scope
An org admin sees their own organization's trail and only that. A client-supplied organization id cannot widen it — the scoping is server-side, not a query parameter you are trusted with.
What is not in here
Reads. The audit log records mutations. It does not record that someone opened a page or ran a query.
Investigations and their tool calls. Those live on the desktop with the ticket or Console thread that produced them, along with the tool chips showing exactly what was called.
Playbook revision history. The desktop keeps a local per-playbook revision trail with its own diffs. The audit log is the portal's equivalent and is the one that survives a desktop being reinstalled.
Using it
The two questions it answers well:
"When did this break?" Find the last change to the relevant playbook or integration and compare it to when investigations started going wrong. Configuration changes reach desktops within about 15 minutes, so line the timestamps up with that in mind.
"Who has been changing what?" Filter mentally by actor. Every row carries the email of the person who made the change, and admin actions are the only ones that appear.