Audit Logs

Audit logs provide a complete, searchable record of every significant action taken in your organization. Every experiment launch, settings change, team member invitation, and metric update is automatically recorded with full context — who did it, what changed, and when.

Why audit logs matter

When something goes wrong — a misconfigured experiment, an accidental deletion, an unexpected traffic allocation change — audit logs let your team trace exactly what happened. They answer questions like:

• Who launched this experiment last Tuesday?
• What was the traffic allocation before someone changed it?
• When was this metric deleted, and by whom?
• Has anyone modified this experiment since it went live?

Audit logs are also essential for enterprise compliance. SOC 2, ISO 27001, and many internal security policies require an audit trail for systems that affect production websites.

Accessing the audit log

Click Audit Log in the left sidebar. The audit log page is available to all organization members — there is no admin gate. Every member can view the full audit trail for their organization.

What actions are logged

The audit log captures every significant action across your organization:

Experiments

• Created, updated (with field-level diff), deleted
• Launched, paused, resumed, completed
• Pending changes published or discarded
• Variations added, updated, or deleted
• Metrics attached or detached, primary metric changed
• Audiences attached or detached

Projects

• Created, updated, deleted
• Datafile published
• Project script updated (via dashboard or CLI)
• Integration settings changed

Organization

• Member invited, joined, removed
• Member role changed
• Custom roles created, updated, or deleted
• API tokens created or deleted
• Organization settings updated

Metrics, Audiences, and Segments

• Created, updated (with field-level diff), deleted

Failed actions

• Permission denied — when a user attempts an action they do not have access to
• Validation failed — when an invalid operation is attempted

Failed actions are logged with a "Failed" status badge and include the reason for the failure.

System actions

• Experiment auto-stopped (reached significance or scheduled end date)
• Retention purge executed

System actions are attributed to "System" rather than a specific user.

Metadata badges

Some actions carry a small badge alongside the action label that distinguishes related rows at a glance. The badges come from the underlying audit row's metadata.kindfield — they don't affect filtering, only display.

• Draft stashed — appears next to anUPDATED action on a flag when the user saved an unpublished draft (auto-stash) without publishing. This signals the row reflects a stash write, not a live publish.
• Draft published — appears next to aPUBLISHEDaction on a flag when a flag draft was published. The badge mirrors the row's action label but makes the source (a draft promotion vs an ad-hoc publish) explicit.

Older audit rows from before this feature shipped have nullmetadata and don't render any badge. The action label alone is still meaningful in those cases.

Filtering the audit log

The audit log provides several filters to help you find specific entries:

• Search — free-text search by resource name (e.g., search for an experiment name to see all actions related to it)
• Date range — filter by start and end date to narrow results to a specific time period
• Action type — filter by what happened (Created, Updated, Deleted, Launched, etc.)
• Resource type — filter by what was affected (Experiment, Project, Metric, Member, etc.)
• Member — filter by who performed the action
• Source — filter by how the action was performed (Dashboard, API, CLI, or System)

Filters are applied server-side before pagination, so they work efficiently even with thousands of entries. Click Clear filters to reset all filters at once.

The detail view

Click any row in the audit log table to open a detail drawer with full information about that action:

• Actor— the name and email of the person (or "System" for automated actions)
• Source — whether the action came from the Dashboard, API, or CLI
• IP address and user agent — the network and browser details of the actor
• Correlation ID — when a single user action triggers multiple log entries (e.g., syncing metrics), they share a correlation ID. Click it to filter the audit log to just that group of entries.
• Changes diff — for update actions, a before/after table shows exactly which fields changed and their old and new values
• Failure reason — for failed actions, the specific reason the action was denied

API endpoint

Audit logs are available programmatically via the REST API:

GET /api/orgs/{orgId}/audit-logs?page=1&pageSize=50&action=LAUNCHED&resourceType=EXPERIMENT

All the same filters available in the UI can be passed as query parameters. The response includes paginated results with a data array and a pagination object.

Retention policy

Audit log entries are retained for 12 months. After that, they are automatically purged by a daily cleanup process. Purged entries cannot be recovered.

GDPR and data privacy

When a user deletes their account, their personal information in audit log entries is automatically anonymized. The actor name is replaced with "Deleted User #[hash]" and the email is cleared. The audit entries themselves are preserved to maintain the integrity of the audit trail, but no personally identifiable information remains.

Immutability

Audit log entries are immutable. Once created, they cannot be edited or deleted by any user, including organization owners and admins. There are no API endpoints for updating or deleting individual audit entries. This is a hard requirement for SOC 2 and ISO 27001 compliance — the audit trail must be tamper-proof.