Skip to main content
The audit log gives workspace owners a chronological record of significant actions taken in the workspace — who made a change, what they changed, and when. It’s useful for accountability, debugging unexpected behavior, and satisfying compliance requirements.

​
When to use it

Check the audit log when:
  • You need to understand who last changed a journey, a secret, or an access setting.
  • A run started behaving differently and you want to trace recent configuration changes.
  • Your organization requires a paper trail for access changes or credential updates.
  • You are investigating an unexpected permission change or a deleted resource.

​
Key concepts

Who, what, when. Each audit log entry records the actor (the user who performed the action), a description of the action, and the timestamp. Entries are workspace-scoped — changes made inside any journey, admin setting, or access configuration in the workspace are captured. Read-only. The audit log is a record, not an interface for making changes. You can read and filter entries, but you cannot edit or delete them. Coverage. The audit log generally covers workspace-level and journey-level actions: user invitations and role changes, secret additions and rotations, environment configuration changes, runner updates, journey creation, deletion, and access changes. The exact set of tracked events may expand over time.
The audit log records intent and authorization-level actions. It is not a full request/response execution trace — run output and step-level execution details live in run results, not the audit log.

​
How it works

Open Admin → Audit log. Entries are listed in reverse chronological order. You can filter by date range or by actor to narrow down what you’re looking for. Entries are retained according to your workspace’s plan. If you need longer retention or export, check your workspace settings for export options.

​
Examples

Tracing a secret rotation. A Cloud Runner job started failing with authentication errors. You open the audit log and filter by the secret name. You find that a secret was updated two hours before the failures started — by the right person, but with a note that it was a partial rotation. You know where to look next. Reviewing access changes before an incident. A journey was run against production unexpectedly. The audit log shows that the runner configuration was updated the previous day and that a new user was granted editor access to that journey. Both are starting points for the investigation.