Skip to content

Audit log

The audit log (/admin/audit-log) records mutating actions taken in Aletheia: who acted, what they did, to what, and when.

Every entry carries the actor, the action, the target, a request identifier, and the time. Where the action carried detail worth keeping — which roles changed, which repositories were selected — that is recorded too.

Entries cover administrative and operational changes: members and invitations, role changes, connections and integrations, state sources, ingest tokens, mapping corrections, triggered work, and organization settings.

An audit entry is written in the same database transaction as the change it describes. Either both land or neither does.

That rules out the failure mode where a change succeeds and its audit entry is lost to a crash, a retry, or a queue that dropped a message — which is exactly the case you most need the log to be right about.

Entries cannot be updated or deleted. The database revokes those permissions rather than relying on the application to never try, so a bug — or someone with database access — cannot quietly rewrite history.

Reading the audit log requires the audit-read permission, which is not granted to every role. Entries are paged newest-first, and each page returns a cursor for the next.

Most entries have a user as the actor. Some have a system actor: work performed by a scheduled job rather than a person, such as an automatic rescan. The actor type distinguishes them, so “nobody did this, a schedule did” is legible rather than looking like an unattributed change.

The audit log covers changes made in Aletheia. Changes made in AWS are a different question, answered by the change timeline — which merges this log with CloudTrail activity and what your pipelines reported.

If you are asking “who changed this security group”, you want the change timeline. If you are asking “who gave that person the operator role”, you want this.