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. The restriction is enforced by the service, not just hidden in the navigation.
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 |
knowledge.* | Knowledge base knowledge.upload, knowledge.update, knowledge.delete, and knowledge.generate when a doc generated on a desktop is first published |
dashboard.* | Dashboard dashboard.create, dashboard.update, dashboard.delete |
generation.update | The per-run cap for doc, playbook and dashboard generation |
mcp.* | Shared integration create, update, delete |
llm.* | AI provider create, update, delete |
The desktop side writes its own entries for things that happen there, including
issue.create when an issue is filed to GitHub or GitLab, issue-tracker
connect/disconnect, and content.publish when an admin publishes a generated doc or
playbook draft.
Paging
50 rows per page, newest first, with Load more to continue. Entries 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. The scoping is enforced by the service and cannot be widened from the browser.
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.