Audit logs

The audit log is Atlas's record of consequential actions taken in your instance — by your team in the dashboard, by your backend over the API, and by automated flows like SCIM. When a security reviewer asks "who changed this, and when?", this is the answer.

What's recorded

Security- and admin-relevant events are written as they happen, including:

• User administration — bans, unbans, manual creation, metadata edits, and impersonation (every impersonation names the operator who did it).

• Configuration changes — any patch to instance config, security policy or branding.

• Credential events — API key rotation and revocation, webhook signing-secret reveals (audited before the secret is returned), and SCIM token revocation.

• Organization lifecycle — invitations, membership and role changes.

Records are kept even when the underlying object is deleted — a revoked API key or SCIM token leaves its row behind precisely so the log can still name it.

Reading and filtering

Open Security → Audit log (or query it over the Backend API). You can filter by:

• Actor — the person or key that acted.

• Action — the kind of event.

• Target — the object acted on.

Results are cursor-paginated, so you can page through a long history reliably.

Exporting

Export the filtered log as CSV (?format=csv on the API, or the export action in the dashboard) to hand to an auditor, load into a SIEM, or archive for a compliance window.

Good practice

• Review impersonation and key-reveal events periodically — they're the highest-trust actions.

• Pull an export into your own log store if you need retention beyond the dashboard window.

• Pair the audit log with webhooks if you want events streamed to your systems in real time rather than pulled.

Next

Help users who get locked out → Account recovery.