Audit logs
What gets recorded, and what does not.
Settings → Audit log, visible to administrators.
What is recorded
Actions that change who can do what, or that affect other people:
- Members invited, removed, or given a different role
- API keys created and revoked
- Connectors created, deleted, or made global
- Access profiles changed
- Settings changed
- Agent sessions revoked
Each entry keeps who did it, what they did it to, and when.
Reading it
The log is shown newest first, 25 entries per page, with page controls under the table. The header shows which slice of the total you are looking at.
Export. The download button next to the refresh control hands you the
entire trail as a CSV file, one row per entry, in the same newest-first order.
Columns: created_at (UTC, RFC 3339), action, actor_email,
actor_user_id, actor_api_key_id, target_type, target_id, detail (the
full JSON payload the table summarises) and id. The same data is available to
scripts at GET /api/orgs/current/audit-log?format=csv with an admin session;
the JSON endpoint takes limit and offset for paging.
Authentication events
Sign-ins, failed sign-ins with the reason, sign-outs and password changes are recorded separately, with the source address. That is what answers "was this account accessed, by whom, from where" after something goes wrong.
What is not recorded
Reading. Searches and content views are not in the audit log. Recording every read would produce an unusable volume of entries and a second copy of your content's access patterns, which is its own risk.
If you need read auditing for a compliance requirement, that is worth a conversation rather than an assumption.
Retention
Entries are kept indefinitely and are never rewritten — the log is append-only by design. On a self-hosted instance you control the database, so you can prune to whatever your retention policy requires.