Audit log

The audit log is owner-only and lives at Settings → Organization → Activity. Every mutating action against the Cloud API emits an audit event - persisted in Postgres, queryable via the UI or GET /api/orgs/{id}/audit.

What’s recorded

Category	Action	When
`cluster`	`cluster.created`	A cluster is registered
	`cluster.updated`	Name / env / labels change
	`cluster.deleted`	Cluster removed from the org
	`cluster.token_rotated`	Install token rotated
	`cluster.action_denied`	A privileged action was rejected by Cloud RBAC
	`cluster.agent.upgrade_requested`	An owner triggered an in-cluster Radar upgrade
`pod`	`pod.exec_started`	A user opened a pod terminal through Radar Cloud
	`pod.exec_ended`	A Radar Cloud pod terminal session ended
`org`	`org.created`	New org
	`org.updated`	Name / domains / default role changed
	`org.sso.portal_opened`	An owner launched the WorkOS Admin Portal
`org_invitation`	`org_invitation.created`	Invite sent
	`org_invitation.accepted`	Invite accepted
	`org_invitation.revoked`	Pending invite revoked
`org_member`	`org_member.joined`	User joined via accepted invite
	`org_member.auto_joined`	User joined via domain auto-join
	`org_member.sso_joined`	User joined via SSO sign-in
	`org_member.removed`	Member removed
`pat`	`pat.created`	Token minted
	`pat.revoked`	Token revoked
`billing`	`billing.checkout_started`	Stripe Checkout session opened
	`billing.subscription_changed`	Plan, quantity, or status changed (covers upgrades, downgrades, payment failures, quantity sync)
`auth`	`auth.signin`	User signs in
	`auth.signout`	User signs out

Cluster connection / disconnection events live on the Notifications stream, not the audit log - they’re operational signal, not a security record. Role changes are recorded on the resulting org_member.* row; the previous role lives in metadata.

Event shape

{
  "id": "ae_01HF...",
  "org_id": "org_01HF...",
  "actor_user_id": "user_01HF...",
  "actor_email": "alice@acme.com",
  "action": "cluster.token_rotated",
  "target_type": "cluster",
  "target_id": "cl_01HF...",
  "target_label": "prod-us-east-1",
  "metadata": { "source": "ui", "rotated_from": "rhc_old..." },
  "ip": "203.0.113.42",
  "user_agent": "Mozilla/5.0 ...",
  "created_at": "2026-04-22T12:34:56Z"
}

The metadata object is per-action. For org_member.joined, expect the inviting actor and the role granted. For billing.subscription_changed, expect the Stripe subscription id, the previous and new plan, and the previous and new cluster quantity. PAT-authenticated actions record the PAT name in metadata.via_pat so you can distinguish browser vs. token activity. Pod exec events record that a terminal session was opened through Radar Cloud. Metadata includes the cluster, namespace, pod, optional container, and session duration on the pod.exec_ended event. Radar Cloud does not record terminal input, terminal output, or shell transcripts.

Filtering

In the UI:

Action - free-text or pick from the action dropdown.
Target type - cluster / pod / org / org_member / org_invitation / pat / billing / auth.
Actor - by member email.
Time range - last 24h / 7d / 30d / custom.

Cursor pagination for older events (50 per page). The pagination cursor is stable, so URL-shareable.

Export

Add ?format=csv to the audit endpoint:

curl -H "Authorization: Bearer rhp_..." \
  "https://api.radarhq.io/api/orgs/<org_id>/audit?format=csv&since=2026-04-01" \
  > audit.csv

Or use the Export CSV button in the UI. Export honors the current filter set.

Retention

Plan	Retention
Free	7 days
Team	30 days
Enterprise	365 days

Retention is currently a read-time filter (events older than the floor are filtered out of every read). Background deletion is on the roadmap.

Programmatic access

GET /api/orgs/{org_id}/audit
GET /api/orgs/{org_id}/audit?action=cluster.deleted
GET /api/orgs/{org_id}/audit?since=2026-04-01&until=2026-04-15
GET /api/orgs/{org_id}/audit?actor=alice@acme.com
GET /api/orgs/{org_id}/audit?format=csv

PAT-based access works for owners only - the same scope as the UI.

What’s NOT in the audit log

K8s API calls outside Radar Cloud. Direct kubectl actions, including kubectl exec, are not captured by the Cloud audit log. K8s itself maintains an audit.k8s.io log if you’ve configured one.
Reads. Ordinary GET / list operations aren’t recorded. Pod terminal lifecycle events are the exception.

Get started

Views

In-cluster capabilities

Integrations

Self-hosted setup

Cloud

Reference

What’s recorded

Event shape

Filtering

Export

Retention

Programmatic access

What’s NOT in the audit log

See also

​What’s recorded

​Event shape

​Filtering

​Export

​Retention

​Programmatic access

​What’s NOT in the audit log

​See also

What’s recorded

Event shape

Filtering

Export

Retention

Programmatic access

What’s NOT in the audit log

See also