Workload Activity History
Workload Activity History 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?
Activity collection is isolated from the optimization path. If the timeline is delayed or unavailable, recommendations and workload updates continue normally.
Availability — Preview: Only selected CloudPilot AI SaaS deployments expose Workload Activity History today, and the rollout is not yet complete. Use the enablement steps below only when CloudPilot AI explicitly confirms support for your cluster.
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.
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. Missing evidence means the value was not recorded safely; it does not mean the value was zero.
Availability and retention
Recording is disabled by default, including on releases that support the feature. Earlier actions are not reconstructed when recording starts, although a recent OOM still present in current Pod status can be observed.
In a supported Preview deployment:
- Turn on Workload Activity History in the cluster’s Workload Autoscaler settings. Allow about one minute for the change to roll out.
- Keep Data Protection Mode disabled. It prevents Activity facts from being uploaded to the SaaS timeline.
- Use the cluster-wide Activity page or the Activity tab for an individual workload.
- Filter the last 24 hours, 7 days, 30 days, or up to 90 days.
- Activity facts are retained for up to 90 days when the capability is available.
Check coverage first
Coverage describes whether the visible timeline is available, current, and complete. It is separate from the outcome of any individual event.
| Coverage state | How to interpret it |
|---|---|
| Healthy | Collection is current and there is no known coverage gap. |
| Delayed | Collection is behind, an upload is pending, or a current local ring is not yet available. Refresh later before drawing a conclusion. |
| Gap | Some older facts were dropped, or missing or invalid sequences were detected. Visible facts remain useful, but the timeline is incomplete. |
| Unsupported | The deployed release or collector does not support the Activity view. |
A Succeeded event can still appear while overall coverage has a gap. Likewise, a coverage gap does not change the outcome of a fact that was recorded. Always read the event outcome and the coverage banner together.
Permission-denied and service-error banners are reported separately from the four coverage states. Resolve the reported access or service problem before relying on the timeline.
Important limits
Workload Activity History is a bounded, best-effort operational timeline. It is not a compliance audit log 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.
- Recording starts from enablement and does not reconstruct earlier optimization actions.
- If the workload object itself is deleted and recreated, its new Kubernetes identity starts a new Activity stream.
- When evidence is missing or coverage is delayed, confirm the current workload resources and Kubernetes events before taking action.
For related behavior, see AutoscalingPolicy, InPlace Update Mode, and OOM Auto-Remediation.