--- id: audit-log title: Audit log sidebar_label: Audit log --- Every mutating API path writes an audit event. The log is at **Audit**. ## What an event carries | Field | Meaning | | ------ | -------------------------------------------------------- | | Action | A dotted name, e.g. `server.created`, `settings.updated` | | Actor | Who did it | | Target | The object acted on | | Detail | A short human-readable note | | Time | When | ## What is recorded Creation, modification and deletion across the product: servers and enrolments, keys and assignments, workflow and step changes, runs triggered, monitors and channels, secret groups and reveals, console sessions opened, settings and member changes, licence installs. Reads are not recorded, with one deliberate exception: **revealing a secret** writes an event, because reading that particular thing is an act rather than a lookup. ## What is not recorded - Sign-ins and sign-out. - Anything inside a console session. - Step output. That lives in the run log, kept under the workflow retention setting rather than with the audit log. ## Retention Audit events are not swept by the workflow log retention setting that setting governs run logs only. Audit history stays until the instance does. :::warning It is a log, not a control The audit log tells you what happened. It does not restrict what can happen, and an admin can do anything an admin can do. Use roles for restriction and the log for accountability. ::: ## Getting events out `GET /api/audit` returns one page of events as JSON: ```json { "events": [ ... ], "total": 3214 } ``` It accepts `limit` (default 50, maximum 200), `skip`, `q` to search actor, details and event type, and `category` to match the part of an event type before the dot — `workflow`, `key`, `server`. `total` counts everything matching the filter, not the page, so a short page is not the end of the log. There is no streaming or push export; if you need events in a SIEM, poll that endpoint, walking `skip` until you have `total`.