Skip to main content
Owners can view the audit log under Settings → Organization → Activity or query GET /api/orgs/{org_id}/audit.

​
What’s recorded

The log covers Cloud administration, authentication, pod-terminal sessions, and MCP tool outcomes. Representative actions include: Self-managed OIDC and emergency-admin sign-ins use auth.oidc_signin and auth.break_glass_signin. MCP membership provisioned on first use emits member.created_jit_oauth. MCP rows identify the actor, tool, cluster, and outcome. Successful high-volume calls may be grouped; successful calls do not store tool arguments or response bodies. Pod-terminal events record the cluster, namespace, pod, optional container, and session duration. They do not record terminal input, output, or shell transcripts. Cluster connection and disconnection events appear in Notifications, rather than the audit log.

​
Event shape

Metadata varies by action. Invitation and SSO joins include the granted role; billing changes include the event type, plan, and status. PAT-authenticated actions use actor_kind: "pat". They identify the user, not which token made the request. PAT creation and revocation events include the token’s name in metadata.

​
Filtering

The UI filters by action, target type, and actor user ID, with a shortcut for MCP activity. Older events load in pages of 50. API callers can also set since and until as RFC3339 timestamps. Filters cannot retrieve events outside your retention window.

​
Export

Use Export CSV in the UI, or add format=csv to the API request. Export honors the current filters.
PAT access requires the owner role, just like the UI.

​
Retention

The audit log is included on paid plans. Hosted Cloud exposes these history windows: The window limits what you can read, not when your organization’s rows are deleted. A sweeper runs at startup and daily to delete hosted audit rows older than 365 days. Self-managed Hubs use their configured retention window for both visibility and deletion.

​
What’s NOT in the audit log

The Cloud log is not a complete Kubernetes audit trail. Direct kubectl calls and ordinary Kubernetes reads and writes through Radar do not produce one Cloud event per API call. Use your Kubernetes API server’s audit log for that record.

​
See also