Audit Log

Audit Log is a workload-level, point-in-time history of what the Workload Autoscaler recommended, planned, attempted, and later observed. Use it to answer questions such as:

• When did a recommendation become ready or fail?
• Which update path was selected, and was it attempted or skipped?
• Did Kubernetes accept the request, and did the Pod later show the target resources?
• Was an OOM, Startup Boost, fallback, or policy-removal recovery involved?

Audit Log collection is isolated from optimization. If recording or collection is delayed or unavailable, recommendation and workload update paths continue normally.

Understand an Audit Log event

The Console can group related facts into one timeline entry: a plan and its change attempts, all stages of one attempt, or detection and classification for one OOM occurrence. Expand the entry to inspect every immutable fact inside it.

Four fields give each fact its meaning:

• Event type (reason) — why the fact was recorded, such as RecommendationReady or ChangeAccepted.
• Action — what area or update path was involved, such as Recommend, InPlaceResize, or ObserveOOM.
• Phase — the lifecycle checkpoint reached by this fact.
• Recorded outcome — the result of this fact only, not the final result of the whole workload operation.

For example, ChangeAccepted + InPlaceResize + Accepted + Succeeded means Kubernetes accepted one in-place resize request. It does not mean that the Pod already has the target resources or that the workload converged.

Filters for Event type, Action, and Recorded outcome apply to individual facts. While one of these filters is active, change-sequence grouping is disabled; one-attempt and one-OOM grouping can remain. Clear the filters to inspect the broader retained sequence.

Event types

Event type is the most specific description of a recorded fact. The Console displays the values below with spaces, for example RecommendationReady as Recommendation Ready.

The most common successful change sequence is shown below. Not every operation uses every stage: a plan can be skipped, an attempt can fail, and an admission mutation, fallback, OOM recovery, or OOM observation can enter the timeline without an UpdatePlanned fact.

Action types

Action describes the controller function or update path involved. It is broader than Event type: one action can produce attempted, accepted, failed, and observed facts.

UpdatePlanned and UpdateSkipped always use the PlanUpdate action. For UpdatePlanned, the optional evidence Code identifies the selected path; for UpdateSkipped, Summary explains why no update ran. Subsequent change facts use the actual change action. A Code can also narrow a broad action, for example by distinguishing fallback rollout from fallback eviction. Treat Summary as bounded context for that fact, not as a stable enum or a complete controller log.

Phase and recorded outcome

Phase answers “where in the lifecycle was this fact recorded?” Outcome answers “what was the result at that checkpoint?” Read them together.

The four Recorded outcome values are:

There is no Unknown Recorded outcome. If no later fact is retained, the later result is unknown to Audit Log rather than stored as an outcome.

Resource and supporting evidence

When safely available, an event includes the affected container and up to three resource views:

• Before — a recorded baseline or pre-change Pod specification, depending on the fact. For an OOM fact, it is the desired PodSpec observed at detection time.
• Target — values the Autoscaler intended to apply.
• Observed — values later seen on the Pod.

A RecommendationReady fact can label each target with a resource stage:

Plan, convergence, OOM, and mutation evidence omit the stage because they describe one effective target, snapshot, or patch.

A dash or missing field means the value was not recorded safely; it does not mean zero. If Evidence truncated appears, optional detail was shortened or omitted to keep recording bounded. The workload action itself was not rejected because of evidence size.

Other visible details include:

OOM detection types and Java subtypes

OOMDetected records the Kubernetes-level detection type. For a Java container, OOMClassified can add a separate best-effort Java subtype; the Console groups both facts into one OOM occurrence. OOMRemediation is a different action and appears separately only when a resource response is attempted.

Detection type

The recorded request and limit are desired PodSpec values observed when the termination was detected. They are not OOM-time memory usage and do not prove which values kubelet had already enacted when the process exited.

Java subtype

unknown is different from a missing OOMClassified fact: the former records an inconclusive Java classification, while the latter can mean classification did not apply or the fact was not retained. Raw container logs are not stored or uploaded by Audit Log. See OOM Auto-Remediation for classification limits and remediation behavior.

Availability, collection, and retention

Audit Log has a bounded local source and a longer SaaS history:

• The Workload Autoscaler keeps at most one WorkloadAutoscalerActivity resource per workload incarnation. Its local ring retains up to 16 events and 16 KiB of controller-owned payload for up to one hour, with at most 1 KiB per event.
• The Agent uploads retained events to CloudPilot AI SaaS. Accepted SaaS events are retained for up to 90 days.
• The cluster-wide and workload views return newest facts first, fetch 100 events per API page, and keep at most 500 events in the current browser view. Narrow the time range or filters to inspect older matching events.

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 the mode resumes collection and can upload events that still survive in the local one-hour ring, including events recorded while the mode was enabled.

Audit Log does not guarantee reconstruction of events that predate compatible components. After an upgrade or restart, it can collect facts still surviving in the local ring and may observe a recent OOM or mutation receipt still present in Pod state, but it does not backfill older history.

Audit Log v1 has been validated with up to 10,000 simultaneously live WorkloadAutoscalerActivity resources in one customer cluster. This is a supported validation boundary, not a runtime admission cap or a limit on workloads managed by core optimization. Above it, Audit Log latency and completeness are not guaranteed and the cluster needs separate control-plane capacity validation; core optimization remains fail-open.

Interpret incomplete history safely

Audit Log is a bounded facts timeline, not an operation state machine. In particular:

• A grouped entry’s Latest fact describes only its newest retained fact; an earlier attempt in the group can have failed.
• An empty result means no retained event matches the selected time range and filters. It does not prove that no action occurred.
• A Running fact records entry into a state and is not updated as a heartbeat.
• A real retry has a separate Attempt ID and its own attempted/result facts.
• Historical facts are immutable. Refreshing can add newly collected facts, but it does not rewrite earlier ones.
• A Pod can disappear, restart history can be overwritten, or a mutation receipt can be unavailable before the corresponding observation is recorded.
• Component outages, denied permissions, queue pressure, deleted or edited Activity resources, or more than one hour or 16 uncollected local events can leave a gap.
• If the workload is deleted and recreated, the new Kubernetes UID starts a new Audit Log stream even when namespace and name are unchanged.

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

When an expected fact or resource value is missing, check the current workload resources, Pod status, Workload Autoscaler conditions, and Kubernetes Events before taking action.

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