Audit logs

The Audit logs page is the operator surface for administrative and security-relevant events. It records who changed operational state, what kind of target was affected, when the event happened, and whether the action succeeded.

Use this page when you need to answer:

1. who changed a Pool, upstream, API key, invite, operator, setting, or session
2. when an administrative action happened
3. whether the action succeeded or failed
4. which Pool or target record was involved
5. which sanitized detail fields changed
6. whether a recent operational issue lines up with an admin action

Audit logs are redacted metadata. They do not show raw credentials, raw Pool API keys, passwords, TOTP secrets, upstream auth.json contents, prompt text, generated content, request payloads, provider responses, or raw secret settings.

The screenshots in this guide use synthetic example data. The production UI shows safe operator metadata to authorized users for their own instance.

Filters

The top filters narrow the table.

Filter	Meaning
Pool	Limits events to one Pool when the event has Pool scope.
Outcome	Limits events to successful or failed actions.
Event	Limits events to one supported audit action.
Actor type	Advanced filter for user or system actors.
Actor	Advanced text filter for actor metadata, such as safe email or id.
Target	Advanced text filter for target metadata, such as target kind or id.
Date from / Date to	Advanced date range filters.

Unsupported filters are ignored with a warning. The table is limited to the latest matching rows for fast operator review. The pager counts at most 10,000 events past the current page; past that it shows a lower bound such as 10000+ and the next page stays available.

Event List

The list is designed for scanning. Events are grouped by day, newest first, and every event reads as one sentence, such as “an operator updated the API key Release assistant in the Pool Example Production”.

Part	Meaning
Event icon	Visual category of the action, such as sign-in, operator, Pool, upstream account, API key, invite, or alert.
Time	Event time in the signed-in operator’s time zone (UTC by default). Click the timestamp to open the details drawer.
Actor	User or system actor that caused the event. Click an actor to filter the list by it.
Action and target	What was done and to which record, such as an API key label, an upstream account label, or an invited email. A target that belongs to a Pool names the Pool, and clicking the Pool filters the list.
Failure marker	A failed action ends with failed and a short sanitized reason. Click it to show only failed events.

Details Drawer

Click a timestamp to open the right-side event drawer.

The drawer shows:

1. event title and timestamp
2. outcome
3. actor
4. target kind
5. request, correlation, and event ids when available
6. action name
7. links to the operator or related record when safe and visible
8. sanitized details

Sanitized details are the useful part of most investigations. They can show changed field names, counts, safe labels, safe prefixes, policy modes, target kind, or route metadata. They should not contain raw secret values or private request content.

Common Events

Common audit events include:

1. operator sign-in and account changes
2. Pool creation, edit, archive, reactivate, and delete actions
3. upstream import, rename, pause, reactivate, refresh, or recovery actions
4. Pool API key creation, edit, rotate, pause, resume, revoke, and delete actions
5. invite creation and acceptance
6. system setting updates
7. MCP token creation, rename, or deletion

Use Audit logs with Request logs when routing behavior changes unexpectedly. Request logs show runtime symptoms; Audit logs show whether an operator or system action changed routing or policy around the same time.

Operational Checklist

When investigating an administrative change, check audit logs in this order:

1. filter by Pool if the issue is Pool-scoped
2. filter by Event if you know the action family
3. filter by Actor when the operator identity is known
4. narrow the date range to the incident window
5. open the details drawer for the strongest matching event
6. review changed fields and related links
7. compare the timestamp with Request logs and System jobs when needed

If an event is missing, confirm the action was inside your visible Pool scope. Owners can inspect global history; assigned admins see Pool-scoped events they are authorized to operate.