Audit Log

Audit Log provides a workload-level timeline of what the Workload Autoscaler recommended, attempted, and later observed. Use it to answer questions such as:

When did a recommendation become ready?
Which resource change was planned, attempted, accepted, skipped, or failed?
Did the running workload later reach the target?
Was an OOM, Startup Boost, fallback, or recovery action involved?

Audit Log collection is isolated from the optimization path. If the timeline is delayed or unavailable, recommendations and workload updates continue normally.

Automatic collection: In CloudPilot AI SaaS, compatible Workload Autoscaler, Agent, API, and Console versions record and collect Audit Log events automatically. There is no dedicated Audit Log setting or feature switch. Older component versions remain compatible with optimization but cannot provide this timeline.

How to read the timeline

Each entry is a fact recorded at one point in the optimization lifecycle. A typical successful sequence moves from a ready recommendation to a planned change, an attempted action, an accepted request, an observed change, and finally convergence.

Audit Log lifecycle

Not every operation uses every stage. For example, an update can be skipped before an attempt, while an OOM observation can appear without a resource change.

Timeline stage	What it tells you
Recommendation	Recommendation calculation started, became ready, or failed.
Planned / Skipped	The Autoscaler selected a change or decided not to act. The entry can include the reason.
Attempted	The Autoscaler sent or began a concrete action such as an in-place resize, Pod replacement, rollout, admission mutation, Startup Boost, or fallback.
Accepted / Failed	Kubernetes accepted the requested action, or the attempt returned an explicit error.
Observed / Converged	Later cluster state showed the change, or the workload reached the recorded target.
OOM and policy facts	OOM detection and classification, policy application or removal, and related remediation context.

Accepted does not mean completed. It means the requested action was accepted by the relevant Kubernetes path. Look for a later Observed or Converged fact before concluding that the running workload reached the target. If no later fact is present, the final result is unknown; the absence of a fact is not itself a failure.

Resource evidence

When available, an entry includes the affected container and three resource views:

Before — resources seen before the action.
Target — resources the Autoscaler intended to apply.
Observed — resources later seen on the workload or Pod.

Recommendation evidence can label a target as Steady or Startup. This helps distinguish the normal runtime recommendation from a dedicated Startup Boost target. OOM facts can also include the affected container and Java OOM subtype.

For an OOM fact, the request and limit are the desired PodSpec values observed when the Workload Autoscaler detected the termination. They are not OOM-time memory usage and do not prove which values kubelet had already enacted when the process exited. Missing evidence means the value was not recorded safely; it does not mean the value was zero.

Availability and retention

Audit Log has two retention layers:

In the customer cluster, the Workload Autoscaler maintains at most one WorkloadAutoscalerActivity resource for each workload incarnation. This best-effort ring keeps events for up to one hour and is bounded to 16 events, 16 KiB of controller-owned payload, and 1 KiB per event. Oversized optional evidence is shortened and marked as truncated instead of blocking the underlying workload action.
The Agent uploads retained events to CloudPilot AI SaaS, where accepted events are retained for up to 90 days.

No dedicated enablement step is required after compatible components are installed. While Data Protection Mode is enabled, the Agent does not start the Audit Log collector and no Audit Log event is uploaded to SaaS. Disabling Data Protection Mode resumes normal collection; the Agent may then upload events still present in the local ring, including events recorded while the mode was enabled. Open Workload Autoscaler > Audit Log for the cluster-wide view, or open a workload and select its Audit Log tab. You can filter retained SaaS history for up to 90 days.

The cluster-wide view applies workload identity and event filters on the server; it does not preload the cluster’s workload roster. Both the cluster-wide view and a workload’s Audit Log tab return newest events first, fetch 100 events per page, and keep at most 500 events in the current view. When that display limit is reached, narrow the time range or filters to inspect older matching events.

Audit Log v1 has been validated with up to 10,000 active WorkloadAutoscalerActivity resources in one customer cluster. This is a validated operating boundary rather than a hard product limit: larger clusters can continue collecting events, but require separate control-plane capacity validation because the Kubernetes API server must cache the bounded resource for every active workload.

Events that predate compatible components are not reconstructed. After an upgrade or reconnect, CloudPilot AI can recover only events that still survive in the one-hour local ring; it does not backfill older history.

Understand completeness

The Console shows retained events and explicit request errors, but it does not present the timeline as a lossless completeness verdict. An empty result means no retained events match the selected time window and filters; it does not prove that no unrecorded action occurred.

Read the recorded outcome as the result of that individual fact only. A Succeeded RecommendationReady fact means a recommendation became available; it does not mean that an update was attempted or that the workload converged. Likewise, the absence of a later fact is not a stored failure result.

The Console reports sign-in, access-denied, unavailable-cluster, timeout, rate-limit, and service errors explicitly and offers a retry. Events already loaded remain visible if a refresh or pagination request fails.

Important limits

Audit Log is a bounded, best-effort operational timeline. Despite its product name, it is not a compliance audit trail and does not guarantee that every intermediate event will be retained or delivered. Do not use it as the only source of evidence for regulatory, security, or change-control requirements.

A component outage, denied permission, overloaded in-memory queue, deleted or edited WorkloadAutoscalerActivity resource, or more than one hour or 16 uncollected events can leave a missing interval.
A Pod can be deleted, or its current and previous termination status can be overwritten by rapid restarts, before an OOM is observed. In those cases the OOM event or its Java subtype may be unavailable.
An unknown Java OOM subtype means the occurrence was retained but the bounded current or previous log could not prove a supported subtype. A missing event is different: it may indicate that the fact was never recorded or was evicted before upload.
Reconciliation does not repeatedly append the same fact. A Running fact records entry into a state; it is not rewritten or emitted as a heartbeat. Each real external retry has a separate attempt that the Console can expand.
A successful mutation can lack a later observed fact if its bounded receipt cannot be written or is replaced before the observer sees it. The earlier accepted fact remains valid but is not proof of convergence.
If the workload object itself is deleted and recreated, its new Kubernetes identity starts a new Audit Log stream.
Historical events are immutable. Refreshing the page can add newly collected events, but it does not rewrite an earlier event.
When an expected event or evidence is missing, confirm the current workload resources, Pod status, and Kubernetes events before taking action.

For related behavior, see AutoscalingPolicy, InPlace Update Mode, and OOM Auto-Remediation.