Skip to main content
The api-server logs an audit event for every privileged action it takes: changing a target’s scale mode, pausing or resuming scaling cluster-wide, cleaning up a removed target, and enrolling new targets. Each event records who took the action, what changed, and whether it succeeded.

​
What’s recorded

Both successful and failed attempts are recorded. A dry-run or count-only enrollment preview isn’t, since nothing is actually changed. Not every dashboard-reachable change goes through this list yet — cost-savings settings is the one left out of this first pass.

​
Who’s recorded

The dashboard forwards the identity of the person who took the action, but only when dashboard authentication can establish one: If per-person attribution matters to you, use oidc mode. htpasswd and disabled auth both share one identity across everyone with dashboard access.
The actor is an attribution hint, not authentication. Anyone holding your apiClientSecret can call the API directly and set it themselves. It’s useful for distinguishing a change made through the dashboard from one made by a script or another integration, not for proving who made it.

​
Reading the log

Each line carries these fields: Pod logs are subject to your cluster’s log retention, so ship api-server logs to your log aggregator if you need to keep this history longer than that.

​
Is there a durable copy?

Yes — every event is also written to a database table before this log line is emitted, so a log rotation doesn’t lose the history. That table isn’t a supported, documented interface yet: there’s no API or dashboard view onto it, its schema isn’t stable across releases, and support for querying it directly isn’t something we can commit to today. Treat the log line above as the supported way to read this trail; persisted: false on a line means even the database copy is missing for that one event, so the log was all there was.