Audit Logs

The audit log gives you a complete, searchable record of every important action in your organization. It records every experiment launch, settings change, member invitation, and metric update. Each entry says who did it, what changed, and when.

1. Type in the search box to find entries by resource name.
2. Use the dropdowns and date range to narrow results by action, resource, source, member, or date.
3. Each row in the table shows who did what, when, and where the action came from.

Why audit logs matter

Something can go wrong: a misconfigured experiment, an accidental deletion, or a traffic allocation (the share of visitors let into an experiment) changed by mistake. The audit log lets your team trace exactly what happened. It answers 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 changed this experiment since it went live?

Audit logs also matter for enterprise compliance. SOC 2, ISO 27001, and many internal security policies require an audit trail for any system that affects production websites.

Accessing the audit log

Click Audit Log in the left sidebar. Every organization member can open it and see the full trail. There is no admin-only gate on this page.

What actions are logged

The audit log captures every significant action across your organization.

Experiments

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

Projects

• Created, updated, or deleted.
• Datafile published.
• Project script updated, from the dashboard or the CLI.
• Integration settings changed.

Organization

• Member invited (one Invited row for each invitation sent, named after the address it went to), joined, or removed.
• Member role changed.
• Custom roles created, updated, or deleted.
• Service tokens created or deleted.
• Organization settings updated.

Metrics, Audiences, and Segments

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

Failed actions

• Permission denied: a user tried an action they do not have access to.
• Validation failed: a user tried an action with invalid input.

A failed action gets a "Failed" status badge and shows the reason it failed.

System actions

• Experiment auto-stopped: it reached significance, or hit its scheduled end date.
• Retention purge executed.

System actions are attributed to "System", not to a specific person.

Metadata badges

A few actions carry a small badge next to the action label, so you can spot related rows at a glance. The badge only changes what you see. It does not change what you can filter by.

• Draft stashed: shown next to an UPDATED action on a flag, when someone saved an unpublished draft without publishing it. This tells you the row is a stash write, not a live publish.
• Draft published: shown next to a PUBLISHED action on a flag, when a flag draft went live. It makes clear the change came from a draft, not a one-off publish.

Rows from before this feature shipped have no badge. The action label alone still tells you what happened.

Filtering the audit log

Use these filters to find specific entries:

• Search: free text, matched against the resource name. Search for an experiment's name to see every action tied to it.
• Date range: pick a start and end day to narrow results to a time period.
• Action type: filter by what happened, such as Created, Updated, Deleted, or Launched.
• Resource type: filter by what was affected, such as Experiment, Project, Metric, or Member.
• Member: filter by who performed the action.
• Source: filter by how the action happened: Dashboard, API, CLI, or System.

Filters run on the server before results are paged, so they stay fast even with thousands of entries. Click Clear filters to reset them all at once.

Delivery tests are hidden by default

Sending a test notification writes an audit entry, and on an organization that tests its destinations a few times these can crowd out everything else. The audit log opens with them hidden, and says so above the filters: Hiding delivery tests. Show.

• Click Show to bring them back into the list. Click Hide to leave them out again.
• Or pick Delivery Test Sent in the Action type filter to see only those entries.

Nothing is deleted or skipped. The entries are always recorded, always retained, and always available through the API. Only the opening view leaves them out.

The detail view

Click any row in the table to open a detail drawer with the full record of that action.

• Actor: the name and email of the person, or "System" for an automated action.
• 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: entries that came from one single operation (such as a metrics sync that touches several rows) share this id. Click it to filter the log down to just that group.
• Changes: for an update, a diff shows exactly which fields changed, and their old and new values.
• Failure reason: for a failed action, the specific reason it was refused.

Programmatic access

The dashboard view described above is backed by a session-authenticated internal endpoint. Click Audit Log in the sidebar to use it; you do not need to be signed in as an admin.

Your audit trail is also available on the public API, at GET /api/v1/audit-logs. This needs a service token with the audit:read scope: a permission you grant the token so it is allowed to read the trail. The endpoint takes the same filters as the dashboard. It also takes a few extras built for integrations, like filtering by one service token or grouping by correlation id.

Retention policy

Audit log entries stick around for 12 months. After that, a daily cleanup job purges them automatically. Once purged, an entry cannot be recovered.

GDPR and data privacy

When someone deletes their account, their personal details in the audit log are anonymized automatically. Their name becomes "Deleted User #[hash]" and their email is cleared. The entries themselves stay, so the audit trail stays complete, but no personal information remains in them.

This section is about team members in the audit trail. For a shopper's data instead, see Shopper Privacy: it covers erasing or exporting one shopper on a GDPR or CCPA request, and how Shopify's compliance webhooks are handled automatically.

Immutability

Audit log entries cannot be changed. Once written, no one can edit or delete one, not even an organization Owner or Admin. There is no API endpoint for updating or deleting a single entry. This is a hard requirement for SOC 2 and ISO 27001 compliance: the audit trail must be tamper-proof.