Audit logs (dashboard)

This page covers the audit log from the dashboard operator's angle: how to find the screen, how to filter, how to export, and worked examples for the situations you'd reach for the log in. For the underlying data model, retention rules, compliance posture, and SIEM ingest, see Security → Audit logs — the canonical reference.

Two surfaces

The org-level view at /[orgSlug]/settings/audit is the one most operators will use. The platform-admin view is intended for AACsearch staff and self-hosted operators.

What is recorded

The full list of recorded actions lives in AUDIT_LOG_ACTIONS (packages/api/modules/audit-log/types.ts). The 30+ entries fall into these groups:

Search queries, document payloads, and individual document reads are not audit events — their volume is too high for an audit log. See Analytics for query-level history.

Filtering

The toolbar at the top of the audit page supports:

• Action — pick one of the recorded action strings from a dropdown.
• User — limit to a specific actor (member email or user ID).
• Target type — index, api_key, member, webhook, widget, connector.
• Date range — dateFrom / dateTo (ISO-8601). Defaults to the last 7 days.

Filters compose with AND. Click a chip to remove it from the active set.

The list paginates at 50 rows per page; the URL preserves the filter set so you can share a link to a specific view.

Reading a row

Each row shows:

• When — UTC timestamp (hover to see the local-time conversion).
• Who — actor name, email, and avatar.
• Action — colored badge with the action string.
• Target — clickable; opens the affected resource if it still exists.
• Source — last 2 octets of the source IP and a truncated User-Agent.

Click the row to expand and see the full details payload — action-specific metadata. For example, change_member_role carries { oldRole, newRole }; update_schema carries the JSON-Patch diff.

Exporting

Two formats are supported, both via the export drawer:

• CSV — comma-separated, headers in the first row. Easiest for spreadsheets and ad-hoc analysis.
• NDJSON — one JSON object per line. Easiest for SIEM ingest.

Click Export to open the drawer. You can:

1. Use the current filter set, or override per-export.
2. Pick the date range (defaults to the current filter range).
3. Pick the format.
4. Submit. The export runs in the background.

When the file is ready (typically seconds; up to a few minutes for very large ranges) you get a notification with a pre-signed download link valid for 15 minutes.

Audit-log export is also available as an oRPC procedure for programmatic / scheduled use — see Security → Audit logs → Exporting for the request shape.

Retention by plan

Retention is plan-dependent:

Rows past retention are soft-deleted (deletedAt) and purged in a background job within 30 days. For longer retention than your plan offers, schedule a nightly export to your own storage.

Full retention rules: Security → Audit logs → Retention.

Worked examples

"Who created this API key?"

1. Open /[orgSlug]/settings/audit.
2. Filter: Action = create_api_key, Target type = api_key.
3. Find the row matching the key's name or prefix.
4. The Who column shows the actor.

If the key has been revoked, the target is no longer clickable, but the details payload preserves the name and prefix.

"We had an incident at 03:14 UTC — what changed in the previous hour?"

1. Open /[orgSlug]/settings/audit.
2. Filter: dateFrom = 2025-10-15T02:14:00Z, dateTo = 2025-10-15T03:14:00Z.
3. Export to NDJSON for archival in the incident folder.
4. Scan for any of: update_schema, delete_index, truncate_index, change_plan, update_curations, revoke_api_key.

Pair this with Analytics → Failed queries for the same window to correlate operator actions with user-visible failures.

"Contractor left two weeks ago — did they create anything that's still live?"

1. Filter: User = the contractor's email, dateFrom = their start date.
2. Look for create_api_key, create_connector, create_webhook.
3. For each row, click the target and verify it has been rotated, revoked, or deleted.
4. Export the filtered view as evidence for your access-review log.

For broader access-rotation guidance: Members & Roles → Removing a member.

"Plan change — when and by whom?"

1. Filter: Action = change_plan.
2. The row's details payload includes the old plan, new plan, and provider transaction ID.

The same event is also recorded by the payment provider — cross-check there if you need an independent witness.

"We're going through SOC 2 evidence collection."

Schedule monthly NDJSON exports and write the output to your evidence vault. The full SIEM-grade audit posture is documented in Security → Audit logs → Integrity.

Enterprise

Enterprise plans can opt into streaming audit delivery (Splunk HEC, Datadog Logs, generic webhook). Events arrive at your endpoint within seconds of the event, in addition to the searchable in-product log. Talk to your account manager to enable it.

Related

• Security → Audit logs — data model, retention, compliance posture, integrity guarantees.
• Members & Roles — add_member, remove_member, change_member_role actions.
• API Keys — create_api_key, revoke_api_key, create_scoped_token actions.
• Analytics — query-level history outside the audit log.
• Plans & Limits — change_plan event details.