Audit, usage & reports

Audit, usage & reports

Every proxied call publishes a durable event, and this page covers the read side of that stream: the audit trail and usage queries, notification channels and routing, and scheduled reports. Because they all read the same event stream, Audit & usage, Budgets, Reports, and (on Pro) SIEM always agree.

Audit & usage

Dashboard: Govern ▸ Audit & usage. Members view, scoped to their org.

The durable record of every call — each row is one completion attempt with who made it, the provider and model that served it, token counts (including cached-token breakdowns), cost when the deployment is priced, latency, and outcome. Streamed calls are audited with their real outcome, captured when the stream ends.

The page is a face over the analytics read API; you can hit the same endpoints directly:

EndpointReturns
GET /admin/usage/callsFilterable audit rows (time / model / outcome)
GET /admin/usage/spendCost, tokens, calls grouped by model
GET /admin/usage/spend-seriesThe same per time bucket (hour / day / week / month)
GET /admin/usage/activityCall/token density by hour-of-day × day

All are org-scoped and accept an optional team/project filter. A member is forced to their own org; the platform admin may pass a scope.

Admin sign-ins have their own log — Govern ▸ Sign-in activity (GET /admin/auth-events, requires VIEW_SECURITY) — for spotting failed or suspicious access to the admin plane.

Notifications

Dashboard: Govern ▸ Notifications. MANAGE_GATEWAY to manage.

Notifications deliver governance alerts off the event stream, per org, over three channel types:

  • Channels — email, webhook (HMAC-signed, SSRF-safe), or in-app (the bell), each with a test-send. An in-app channel targets the whole org or chosen members, teams, and projects.
  • Routing — per-scope, most-specific-first rules mapping an event category (guardrail triggers, budget thresholds, SOAR actions, SIEM detections, report completions) to channels and audiences, with severity thresholds. Apply recommended plants a starter set.
  • Delivery log — what was sent, where, and whether it succeeded.
  • Preferences — a dedupe cooldown and a quiet-hours window with a timezone; CRITICAL always sends.

Email requires an SMTP server, configured per-org under Settings ▸ Mail server (with a send-test). Webhooks and in-app channels need no mail server.

Reports

Dashboard: Govern ▸ Reports. VIEW_REPORTS to view; MANAGE_REPORTS (operator and up) to author, schedule, and run.

Reports turn usage data into shareable artifacts: branded PDF, CSV, JSON, or HTML, on demand or on a schedule. A report has a definition (the saved spec) and produces runs (generated artifacts stored with a TTL).

A definition consists of:

  • Dataset — picked from a typed catalogue, never raw SQL: spend by model, usage over time, activity, guardrail findings. Datasets are portable across the Postgres and OpenSearch backends unchanged.
  • Scope and time window — org / team / project; this period vs last, with period-over-period deltas.
  • Format and schedule — PDF/CSV/JSON/HTML; cron-like schedules or Run now.
  • Delivery modelink only (the secure default: recipients get a dashboard link, no data leaves) or attach the file (email attaches it; a JSON webhook posts it). Delivery routes through Notifications.
  • Optional password — a native-password PDF, a self-decrypting HTML page, or a .gpg file for CSV/JSON. Independently, every stored artifact is always encrypted at rest in the object store.

Artifacts live in the object store (a local directory on one host, any S3-compatible store on Distributed) with a TTL (default one day) and per-org ceilings; downloads stream through a gated controller so tenant isolation holds.