Trace a request, prove a configuration change, and see how long this appliance keeps each class of evidence.

Event Logs is the appliance's audit trail: every API request, sign-in, detection, configuration change, error and slow request, each stamped with a correlation ID you can follow across the whole pipeline.

What do I need?

Licence: Any
Role: admin_userviewer

Prerequisites

You are signed in as admin_user, superadmin, viewer or auditor. All four read this page.
Only a superadmin can run the cleanup sweep from this page.
Retention windows and enforcement are changed under Settings, not here.

Every event carries a category — Request, Security, Audit, Error or Performance — and the category, not the event type, is what decides how long the row is kept.

Screenshot pendingEvent Logs with six category stat tiles, the search and category filter bar, and the events table/assets/screenshots/event-logs@0.4.png

Find an event

Open the page

Select Security & Compliance → Event Logs.

Six tiles count Total events, Requests, Security, Audit, Errors and Performance. They are all-time counts with no date filter — the note says so, and explains why the Dashboard's tiles are smaller.

Narrow by category

Select a tile, or set Category to Request, Security, Audit, Error or Performance.

A selected tile reads Showing {label} only — click to clear.

Search for the event type

Type into Search event type….

The search matches the event type string, not the payload. It is applied by the gateway, so the counts and the pager follow it.

Set the date range

Set Start date and End date.

Leave both empty to search all time.

Open the row

Select View.

Event Details shows Basic Information (id, tenant, session), HTTP Request, Payload, and — depending on the event — Audit Changes, Error Information and Metadata.

Trace one request end to end

Every request is stamped with a correlation ID, and every event the pipeline writes while handling it carries the same ID.

Copy the correlation ID

In Event Details, select the Correlation ID value.

A {label} copied to clipboard toast confirms it.

Pull the whole trace

Select Trace Request.

The view returns every event sharing that correlation ID, in order — the request start, the detections, the provider call and the completion — so a single user complaint resolves to one ordered list rather than a search.

Prove a configuration change

Filter to the audit category

Set Category to Audit.

Audit rows are the create, update and delete events: RESOURCE_CREATED, RESOURCE_UPDATED and RESOURCE_DELETED.

Read what changed

Open the row and read Audit Changes.

It names the Resource, the Fields Changed, and the values Before and After, so a role change is distinguishable from a re-saved form.

Check whether a control was weakened

Search for POLICY_PROTECTION_CHANGED.

One row is written per changed field, always with both the previous and the new value, so a disable, a downgrade from reject to mask, and a re-enable are all separately visible. Renames and priority edits write nothing.

Check the retention policy

The toolbar carries a live retention line, read from the policy rather than hard-coded. It reads either Retention (enforced): {windows} or Retention (configured, NOT enforced): {windows}, and a category set to 0 renders as never deleted rather than as zero days.

Read the line

Look at the retention note beside the table.

When enforcement is off it adds: The sweep runs in survey mode: it reports what it would remove and deletes nothing, so rows older than these windows are still on disk.

Run the sweep

Select Cleanup old logs, read the dialog, then confirm.

With enforcement off the dialog says the run will report what it would remove and delete nothing. With enforcement on it warns that rows past their category window are permanently deleted and the action cannot be undone.

Danger

Enforcement ships off, so no category is trimmed on a default appliance and rows older than every window below are still on disk. A window is a statement of intent until somebody turns enforcement on under Retention.

Shipped windows

Category	Window	Holds
Request	30 days	API traffic
Performance	30 days	Slow requests and timeouts
Error	90 days	Exceptions and failures
Audit	365 days	Configuration changes
Security	400 days	Detections, blocks and sign-ins

The Security window has a floor: with enforcement on, the gateway refuses any value between 1 and 179 days, because that would delete detection evidence inside the six-month minimum the EU AI Act sets for deployers. Use 0 to disable the sweep for that category instead.

Warning

The generated event-type reference prints 90 days for the Security category. That figure is hard-coded in the generator and does not match the shipped policy of 400 days above, which is the value the appliance actually holds.

Fields reference

Table columns

Column	Shows
Category	Request, Security, Audit, Error or Performance
Event type	The registry name of the event, for example `AUTH_SUCCESS`
Method	The HTTP method, for request-derived events
Path	The request path
Status	The HTTP status code
Duration	Processing time in milliseconds
IP address	The client address recorded for the request
Timestamp	When the event was written

What each category holds

Category	Typical event types
Request	`REQUEST_START`, `REQUEST_COMPLETE`, `AI_USAGE`
Security	`PII_DETECTED`, `MESSAGE_BLOCKED`, `MESSAGE_MASKED`, `HAP_DETECTED`, `JAILBREAK_DETECTED`, `AUTH_SUCCESS`, `AUTH_FAILURE`, `POLICY_PROTECTION_CHANGED`
Audit	`RESOURCE_CREATED`, `RESOURCE_UPDATED`, `RESOURCE_DELETED`, `FILTER_BUNDLE_EXPORTED`, `PASSWORD_RESET_LINK_ISSUED`
Error	`EXCEPTION`, `VALIDATION_ERROR`, `PROVIDER_ERROR`
Performance	`SLOW_REQUEST`, `TIMEOUT`

The full classified list — every type, its category, and which feed reads it — is the generated event type reference. Readers derive their type sets from that registry rather than keeping their own allowlists, so a newly registered type is displayed everywhere it belongs without a second edit.

Verify

Sign out and back in. A row with the event type AUTH_SUCCESS appears in the Security category within a refresh.
Change any admin object — rename a filter, edit a tenant. A RESOURCE_UPDATED row appears in the Audit category naming the fields that moved.
Select Trace Request on any request-derived row. The trace returns more than one event for a request that did real work.
The retention line names five categories and states whether enforcement is on.

If it fails

No logs found. — the filters exclude everything. Clear Category, the search box and both dates before concluding the log is empty.
The Cleanup old logs button returns a 403 — the sweep is superadmin-only, while the page itself opens for admin_user. The button is not hidden for other roles, so an admin who is not the superadmin sees it and cannot use it.
Retention policy unavailable in the toolbar — the policy could not be read. The UI says so rather than printing a number it cannot stand behind.
The sweep reports Retention is not enforced — nothing was deleted. — that is the default state, not a failure. Turn enforcement on under Retention.
Enforcing a {n}-day window on SECURITY would delete detection evidence inside the six-month minimum the AI Act sets for deployers. Use 0 to disable the sweep for this category instead. — the value you tried is below the floor.
Failed to cleanup logs — the sweep itself errored. Check the gateway logs; the policy is unchanged.

Next steps

Retention — change a window or turn enforcement on.
All detections — the detection subset of this log, merged with the chat, extension and document stores.
Access control — decide which roles read the audit trail.

Search the event log