Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.novacula.io/llms.txt

Use this file to discover all available pages before exploring further.

The Audit log is a strict who-did-what record for every action that happens inside an organization through the Dashboard UI or the platform’s APIs. Each row carries an actor, a target, a typed action, a timestamp, and a sanitized details payload. Use it for compliance reviews, incident forensics, and “who changed this setting?” investigations. The page lives at Audit log in the sidebar of the Dashboard UI. A self-scoped slice of the same data is embedded on your profile page as My recent activity — see Manage your account.

​
Audit log vs other streams

Three streams the platform exposes, easily confused:
StreamCarriesWhen you use it
Audit logActor + target + typed action + immutable timestampCompliance, security investigations, “who did this?”
Events feedLifecycle facts about resources (no required actor)Ops triage, “what happened, when?”
Alert incidentsActionable conditions with open → resolved lifecyclePaging on-call, webhook delivery
Many control-plane events also produce an audit row — the events feed links to its matching audit row via auditActionId.

​
What each row carries

FieldContent
actorThe user who performed the action (id, display name, email). Always present — unlike events, audit rows are never authorless.
actionA typed value from the AuditAction enum. See the Audit action catalog below.
targetThe entity acted on — kind (node, executor, api_key, organization, user, …) and id. Renders as a link to the target’s detail page when applicable.
scopeorganization (most actions) or platform (admin-level actions like user.banned, admin.impersonation.started).
detailsSanitized JSON of action-specific fields — changedFields, fromRole / toRole, expiresAt, etc. Per-action allow-lists strip everything else; secrets and noisy nested objects never enter the log.
sourceui / api / system. Hidden from the org view (kept on the admin surface).
createdAtServer-side timestamp.
Rows are immutable and never auto-resolve — there is no lifecycle, only a creation timestamp.

​
Filtering

The full-page log supports filters:
  • Action type — multi-select against the AuditAction catalog.
  • Actor user — free-text by name or email.
  • Target kind + target id — for narrowing to a specific entity.
  • Date range — from / to.
Filters compose; the URL reflects active filters so a particular view is shareable.

​
Export to CSV

The full-page log has an Export CSV button. The export aggregates every row matching the current filters and downloads a CSV with columns: timestamp, actor, actor_email, action, target_type, target_id, target_name, details. File name: audit-activity-log-<YYYYMMDD>.csv. CSV export is intentionally disabled on the My recent activity embed on the profile page — that view is a personal slice, not a compliance artefact.

​
Role visibility (target)

The audit log is org-scoped: every signed-in user in the org can read entries in their active organization. The platform-target visibility narrows what each role sees:
RoleSees
Org OwnerAll events in the org (own + Admins’ + Members’).
Org AdminOwn events + every Member’s events. Not Owner-authored events.
Org MemberOwn events only.
System AdminAll events in the org; can also read across any org from the admin console.
The My recent activity embed on the profile page is always scoped to actor = self, regardless of role.
Role-aware narrowing on the full Audit log page is being rolled out; until the gate ships, signed-in members may see a broader feed than the target above. Treat the table as the contract you can rely on once the rollout completes.

​
Audit action catalog

Every action emitted by the platform is a typed enum value. Examples by domain:
  • Nodes — node.created, node.updated, node.deleted, node.start.requested, node.stop.requested, node.restart.requested, node.tags.updated, node.group.updated.
  • Executors — executor.deleted, executor.tags.updated, executor.group.updated.
  • API keys — api_key.created, api_key.updated, api_key.revoked, api_key.deleted.
  • Users — user.password.changed, user.profile.updated, user.global_role.changed, user.organization_role.changed, user.organization_membership.added, user.organization_membership.removed, user.banned, user.unbanned, user.deleted.
  • Organizations — organization.created, organization.updated, organization.deleted, organization.invitation.created.
  • Notifications — notification_settings.updated.
  • Impersonation — admin.impersonation.requested, .approved, .denied, .revoked, .started, .stopped.
  • Auth lifecycle — user.registered, session.signed_in, session.signed_out, user.session.terminated, invitation.sent, invitation.accepted, invitation.revoked.
Per-action allow-lists determine which fields enter the row’s details. The catalog is curated server-side; new actions are added via the platform’s release cycle.

​
Permissions

  • Read the org audit feed — any org role (subject to the role visibility table above).
  • Export CSV — same as read.
  • Read the per-user My recent activity embed on your own profile — every signed-in user, self-scoped.
  • The audit log itself is append-only — there is no delete, edit, or dismiss UI for any role.