Audit logs

AACsearch records administrative actions to a tamper-evident audit log. The log is per-organization, queryable from the dashboard, and exportable in CSV or NDJSON for ingestion into your SIEM.

This is your record of "who did what, when, and from where" — for incident response, compliance evidence, and routine review.

What is recorded

Each row stores:

What is not recorded: search queries, document payloads, individual document reads. Those volumes are too high for the audit log; query-level data lives in the analytics layer with a shorter retention window.

Retention

Audit log rows live for 365 days for organizations on Business or higher plans, and 90 days for Starter. After that, rows are soft-deleted (deletedAt set) and purged in a background job within 30 days.

If your compliance program requires longer retention, export regularly to your own storage — see below.

Browsing in the dashboard

1. Open Organization → Audit log.
2. Filter by action, user, target type, or a date range.
3. Click a row to see the full details payload.

The dashboard shows the most recent 10 000 rows directly; older rows are streamed from the database as you scroll or via export.

Exporting

Audit log export is exposed as an oRPC procedure. From the dashboard, Audit log → Export triggers a background job and emails a signed download link when it's ready.

Programmatic export:

POST /api/orpc/auditLog.export
Content-Type: application/json
Authorization: Bearer ss_search_…  (scope: admin)

{
  "format": "ndjson",         // or "csv"
  "from": "2026-04-01T00:00:00Z",
  "to":   "2026-05-01T00:00:00Z",
  "actions": ["create_api_key", "revoke_api_key"]   // optional filter
}

The response is a job ID; poll auditLog.getExportStatus until the job completes and returns a pre-signed download URL (valid for 15 minutes).

For continuous shipping to a SIEM, schedule the export to run nightly and write the output to your own object storage. A streaming, push-based delivery (Splunk, Datadog) is on the enterprise roadmap — talk to sales if you need it now.

Integrity

Audit log rows are append-only from the application's perspective: there is no oRPC procedure that updates or deletes a row. Soft-deletes via deletedAt are written by the retention job only, and the original row remains in cold storage backups for the data residency region's backup window.

This is not blockchain-grade tamper-evidence. For organizations that need cryptographically chained logs, use the export above and chain on your side, or contact sales about the enterprise add-on.

Common use cases

• A leaked key. Filter action = create_api_key OR revoke_api_key, then cross-reference with the analytics endpoint to find when the key was last used.
• Unexpected reindex. Filter action = reindex_started, group by userId. Reindexes are expensive — they should match a deploy.
• Member offboarding. When you remove someone, the log shows everything they did up to that point. Keep the export.
• Region change. action = update_data_residency_region should appear only when you deliberately move data. If it appears unexpectedly, escalate.

Common mistakes

• Relying on the dashboard for long-term storage. Once retention expires, the row is gone. Export.
• Not exporting machine actions. SCIM and CI-driven actions are in scim_audit_log and audit_log respectively. Make sure your export covers both.
• Treating "no row" as "didn't happen". A row is written when the action succeeds. Failed attempts at the API layer may not produce an audit row — they produce request logs instead. For security investigation, correlate audit logs with the request log shipped to your observability stack. See Observability.

See also

• API keys — the most common subject of audit-log filters
• SSO and SCIM — scim_audit_log records provisioning actions separately
• Observability — request-level logs and metrics