Audit Log
Every change to rules, releases, access, and credentials in your organization, with CSV/JSON export and SIEM streaming.
What it is
The audit log is the organization’s permanent record of who did what, and when. You reach it from the organization’s admin area, and it opens on the full list of events with the newest first. Nothing you do on this screen changes an entry: the log is read-only, and entries are written as the actions happen rather than reconstructed later.
Auditable actions cover the whole surface of the product, including:
- Creating, changing, and deleting rules, conditions, and action sets.
- Release activity: submitting, approving, rejecting, and publishing.
- Deployment pipeline activity: cutting a release, promoting one from one stage to the next, requesting and approving or rejecting a promotion, expediting one past its gate, rolling a stage back, returning a release to draft, and changes to the pipelines themselves.
- Changes to projects, organizations, and environments.
- Changes to governance policy, access and security policy, custom role definitions, and the author seat ceiling — plus every access review that is exported.
- Issuing and revoking API keys, MCP tokens, and host credentials.
- Sign-ins, including sign-ins that were refused, and accounts being erased.
- Backups and compliance archives: each one written, changes to where they are written, and a destination that has started failing.
- Adding or removing a paid add-on.
- Reads of secrets, and updates to settings and variables.
Removing someone’s account clears their name and email address, but the trail of what they did stays exactly as it was. Their past entries simply read Deleted user from then on, so a record of an approval never turns into a record of nothing.
Reading a row
Each row is one event, described across five columns.
| Column | What it tells you |
|---|---|
| When | The timestamp of the event. |
| Action | What was done, named for the thing that happened, such as RuleSetUpdated or ReleasePublished. If the attempt was refused or failed, the action carries a refused badge, and its tooltip spells out that the action was attempted and refused. |
| Actor | Who did it, shown as the person’s name. An account that has since been erased reads as Deleted user, and an invitation nobody has taken up yet reads as Invited — the entry stays readable either way. When the action came from a machine credential instead, the kind of actor is shown in place of a name, with a tooltip clarifying that this was not a person: an API key, an MCP token, a managed host, or the system itself. The actor’s IP address is shown alongside when it is known. |
| Resource | The type of thing that was acted on and its name. The name recorded is the name the resource had at the time of the action, so renaming something later does not make its history unreadable. |
| Details | Small key and value chips carrying the metadata that makes the event meaningful, such as counts, version numbers, and role names. |
Audit entries never contain request or response bodies, variable values, or secrets. They record the action, the actor, the resource, and a little metadata about it. If you need to see the data a run actually worked with, that belongs to run logging instead.
Results load 50 events at a time. While more remain, a Load more button at the bottom of the list fetches the next batch. If nothing matches what you are looking at, the screen says so rather than showing an empty table.
Filtering
A filter bar sits above the list. Set the filters you want and press Apply; Clear resets them and returns you to the full log.
| Filter | How it works |
|---|---|
| Action | A dropdown listing every auditable action, so you can narrow to one kind of event. |
| Actor email | Narrows to the events a specific person caused. |
| Resource type | Free text naming the kind of resource, such as RuleSet, Project, or ApiKey. |
| From and To | A date range. Either end can be left open. |
| Refused attempts only | A toggle that hides everything that succeeded, leaving just the attempts that were refused or failed. |
When you are investigating rather than reporting, the refused-attempts toggle combined with a tight date range is usually the fastest way in. Refused sign-ins and refused credential use are the events most worth looking at first.
Exporting
An Export button appears in the page header, offering CSV or JSON. The export honors whatever filters you currently have applied, so narrowing the list first narrows the file. When the export finishes, a message tells you how many events it contained.
There is a ceiling on how many events a single export can contain. If your export hits it, the file is explicitly flagged as truncated and you are told so. Narrow the date range and export again in smaller slices rather than treating a truncated file as complete.
Export is available on the Enterprise plan. On other plans the button is not shown, and the log remains fully browsable on screen.
Streaming to a SIEM
A Streaming card on the same screen lets an organization admin forward every audit event, in near real time, to a security information and event management system of their own, such as a Splunk HTTP Event Collector or a comparable collector. Once it is on, events keep flowing without anyone having to remember to export.
| Setting | What to enter |
|---|---|
| Enabled | Turns forwarding on and off. Turning it off stops delivery but keeps the configuration. |
| Destination URL | The HTTPS endpoint that receives the events. |
| Auth header name | The header your collector expects the credential in, commonly Authorization. |
| Auth header value | The credential itself, entered once. |
Only HTTPS destinations are accepted, and private or loopback addresses are refused. This is an outbound webhook to a system you control and operate, so it has to be reachable from outside your own network. An address that only resolves inside a private network, or that points back at the machine you are configuring from, will not be saved.
After you save it, the stored credential is never returned again. The card shows only a short Stored: preview of its first characters so you can tell that one is set. If you edit the streaming settings later and leave the value blank, the existing credential is kept as is. Fill it in only when you are setting or rotating it.
Testing and delivery health
Send test event fires a real probe at the configured destination and reports back whether it was accepted. Use it once after saving, and again after you rotate the credential or change the collector.
The card then reports on delivery on an ongoing basis:
- When delivery is healthy, it shows the time of the last successful delivery and a running total of events delivered.
- When delivery is failing, a warning banner explains which kind of failure it is. Either the destination has never accepted an event, which usually means the URL or the credential is wrong, or delivery has been failing since a given time, in which case you are shown how many consecutive attempts have been refused and the last error reason when the destination gave one.
Nothing in your collector tells this screen that a token expired or an endpoint moved. The delivery health line is where that shows up, so it is worth a glance whenever the receiving system changes.