Secrets are not stored raw in audit payloads. Values whose keys look like
credentials, tokens, API keys, or passwords are redacted before insertion.
Example event
The JSON export uses the same presentation-safe shape as the audit detail view. Storedtarget, before, and after values are mapped to the export’s
resource and diff fields after public-ID filtering and redaction.
Opening the audit log emits audit_log.view. A mapped export row for that real
application event has this shape:
Not recorded; the UI does not invent a
value.
Filter and export
Open a project’s audit log from project settings. Admin and Auditor roles can select a 7, 30, or 90 day window, or all retained rows, then filter the loaded events by search text, event type, actor, and status. The server loads the newest 200 matching rows for the selected date window. CSV and JSON downloads contain only the rows visible after the in-page filters are applied. When more than 200 rows match, the UI reports that the result is truncated. An export is therefore a filtered working set, not a complete database archive. CSV contains timestamp, actor email, event, resource type and id, operation, status, event id, correlation id, masked source IP, user agent, app version, and failure reason. JSON also retains the actor, source channel, resource, diff, and metadata objects shown in the detail view.Retention
Audit rows are kept forAUDIT_RETENTION_DAYS, defaulting to 365 days when the
variable is unset. The value must be between 1 and 3650 days.
Worker maintenance can run a daily audit-log purge, and the self-hosted purge
route calls the same retention helper. The purge deletes rows older than the
cutoff; it does not rewrite retained rows.
Action registry
The actions below are the current audit-log action values emitted by the application.API means a project-scoped API-key call; those rows have a null
actor and are shown as System in the audit UI.