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 record of who did what, and when, kept for as long as your plan’s retention. 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 until it reaches the end of its retention. 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. A few older entries read Unknown user: they named the person by an email address that more than one account has used, so the entry cannot say which of them it was. 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.
Retention
Every event expires when it reaches the retention of the plan it was recorded under: 7 days on Free, 30 on Pro, 90 on Team, and seven years on Enterprise. The page header says how long your organization keeps them. Events are recorded on every plan, including the ones that cannot browse the log. Enterprise events recorded before the seven-year default was introduced were written with no expiry, and keep it.
On Enterprise, an organization admin can keep events longer than seven years (10, 15 or 25 years, or indefinitely) from the Retention card on this page. The choice is itself recorded in the log. It applies to events recorded from then on: each event’s expiry is fixed when it is written, so changing the setting neither extends nor cuts short events already stored. If the organization later moves to a lower plan, that plan’s retention applies to new events, and the choice comes back into force on a return to Enterprise.
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. While one is stored, the Auth header value box shows a row of dots 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.
When the destination is down
Events your destination does not accept are held, not dropped.
- A delivery that fails is retried a few times over about two and a half minutes, which rides out a collector restarting or briefly pushing back. A refusal that waiting will not fix, such as a rejected credential or an endpoint that does not exist, is not retried.
- If the destination still has not accepted the events, they are held, and the warning banner on the card says how many are waiting and since when. While events are held, newer events wait behind them rather than going out first.
- Every five minutes the held events are offered to the destination again, oldest first. Once it accepts them, the card shows the catch-up until nothing is left, and new events go straight through again.
- Turning streaming off keeps whatever is held, and it is sent when you turn streaming back on. If you point streaming at a new destination while events are held, they are sent to the new one.
Delivery is at least once. After a retry, your destination can receive an event it already has, so use each event's id to recognise and drop duplicates.
Held events are read back from your audit log when they are sent. An event that reaches the end of your retention period before the destination comes back can no longer be streamed; it is gone from the audit log too. To recover a long outage in full, use export or the compliance archive.