Skip to main content
The audit log is a running record of what the platform did with your requests. Every time the platform routes a request, runs it through the firewall, or you change a setting like switching a service on, it writes an entry here. You can use it to see what happened and when, to check that things behaved the way you expect, and to keep records for your own compliance. You will find it under Platform > Audit logs.

​
What we record, and what we don’t

The audit log keeps the details about each event, not the content of your requests. It records things like which part of the platform acted, what it decided, when, and for which request. It does not store your prompts, the model’s responses, or any of the data inside them. This is deliberate. Keeping the content out of the log is part of how the platform protects the personal data in your requests. So the audit log is safe to read, share with a colleague, and export, without exposing the underlying request data.

​
Reading an entry

Each row is one event. From left to right you will see:
  • Time. When the event happened. Hover to see the exact timestamp.
  • Component. The part of the platform that acted, for example the firewall, the router, or your account settings.
  • Action. What it decided or did, for example Allowed, Blocked, Flagged, Enabled or Disabled.
  • Request ID. The identifier of the request the event belongs to. Events that share a request ID are part of the same request.
  • Actor. The person who triggered the event, or System when the platform acted on its own.
Click any row to open a panel with the full details for that event. This is where you see the extra context, such as what the firewall found or which service a setting change applied to.

​
Opening the trace for a request

When the request behind an entry was recorded by Observability, the panel shows an Open trace link beside its request ID. A trace says what the request did and what it cost, which is the half the audit log deliberately does not keep. The link is there or it is not, and there are two reasons it usually is not:
  • Most entries record no inference at all. Billing, members, single sign-on and settings changes never called a model. Memory, guard and retrieval make model calls the trace explorer does not cover.
  • Traces are removed before entries. On every plan the trace retention window is shorter than the audit one, so an entry outlives the trace it points at. On Business that is a year against ninety days.
We show nothing rather than a greyed link, because a greyed link would say a trace exists and is being withheld, and in both of those cases that would be untrue. The request ID stays either way.

​
Why a request went where it did

A router event also records the targets it did not use, and why. If a request named several models, or resolved an alias, the event lists each one that was dropped with its reason: This is what makes enforcement evidenceable rather than merely real. When a model is disabled or an external route refused, the log shows the decision instead of leaving a silent absence. Only slugs and reasons are recorded, never any part of the request’s content. A request that reaches no usable target is not served at all, so it has no router event to carry those reasons. It gets its own entry instead, with the action Refused, naming the model you asked for and the reason each candidate was dropped. That is the entry to look for when you need to show that a request was blocked rather than quietly rerouted: filter the Action column to Refused to see every request the platform turned away and why.

​
Finding what you need

The newest events show first. To narrow the list, use the controls above the table.
  • Component and Action let you filter to specific kinds of events. You can pick more than one. Every component and outcome the platform records is offered, including ones your organisation has never produced: filtering to one of those returns an empty page, which is an answer. An option missing because something never happened could not be told apart from an option the filter had forgotten, and on a compliance record those two must not look alike.
  • Date filters to a range, which is useful when you are looking into something that happened on a particular day.
  • Search matches on the request ID and on the actor’s name. It is not case sensitive, so you do not need to match the capitalisation.
Filters take effect as soon as you choose them, and search runs a moment after you stop typing. The page address updates as you filter, so you can bookmark a filtered view or send the link to a colleague and they will see the same thing.

​
Exporting

Use the Export CSV button to download the log as a spreadsheet file. The export includes whatever filters and search you have applied, so you get exactly the rows you are looking at rather than the entire log. The file has one row per event, with the time, component, action, request ID, actor and details. It opens in any spreadsheet program. As with the page itself, the export contains only event details, never the content of your requests. This is handy for keeping records, for sharing a period of activity with an auditor, or for doing your own analysis outside the platform.

​
Good to know

Entries do not change. Once an event is recorded it stays as it is. The platform never edits an entry, it only adds new ones, so the log is a reliable history. How long entries are kept depends on your plan. Free and Pay as you go keep 14 days, Team keeps 90 days, Business keeps 365 days, and Enterprise keeps 730 days. After that they are removed automatically. If you need to keep activity for longer, export it with the button above and save the file on your side before it ages out. Each entry belongs to your organization. You only ever see your own organization’s activity. The log fills in as you use the platform. A new account has little in it. As you send requests and turn on services, the matching events start to appear.