Audit log
What is recorded, what is deliberately not, and who can read it.
The audit log records every mutating action, and reads that disclose a credential.
GET /audit-logs requires a session and an operator role.
What a row carries
| Field | |
|---|---|
action | A closed union of action names — a typo is a compile error rather than an un-greppable row. |
actorId | Who did it. |
targetType, targetId | What it was done to. |
organizationId | The scope. |
ipAddress | The client's address — real only when TRUSTED_PROXY_HOPS matches the deployment's proxy count. |
metadata | Action-specific detail. |
| Timestamp |
What is never recorded
No secret's value ever appears in the audit log
Not a session token, not an API token's issued value, not a TOTP seed, not a recovery code, not a notification channel's signing secret, not a managed service's generated credentials, and not an environment variable.
What is recorded is the thing an operator actually needs:
- for a revoked session, who ended whose — never the token,
- for a recovery code, how many are left — because that is the number that tells you how close somebody is to being locked out,
- for an API token, its readable prefix — so a revocation can be traced to a token,
- for a notification channel, its target — never its secret.
What is covered
Authentication (sign-in success and failure, sign-out, password change and reset, session revocation), two-factor enrolment and use, API token creation and revocation, alerts and notification channels, managed services and their lifecycle, and the resource mutations across projects, applications, deployments, domains, variables, volumes, and servers.
The one read that is audited
GET /services/:id/connection — the only route that discloses a managed service's generated
credentials — writes an audit row every time it is read. A credential that can be read without
a trace is a credential nobody can reason about afterwards.