Start from the restart and read backwards. The vpa-controller writes to `container.googleapis.com/vpa-controller` in Cloud Logging [4]. Filter to the target workload and the chain is there. Under `InPlaceOrRecreate`, an `APPLY_RECOMMENDATION_IN_PLACE` entry records the attempt to change a running container's requests and limits without a restart [9]. When that attempt does not land, the `EVICT_POD` entry that follows is the updater falling back to recreation [8]. `APPLY_RECOMMENDATION_ON_EVICTION` then shows what the replacement pod was actually admitted with [16]. Four operation types, one timeline [6].
That is the case Google's own writeup names as the hard one: a pod evicted during an overnight batch job, or an in-place resize that failed quietly because the node had no room, diagnosed the next morning [c3b]. The entries are stored as first-class control plane logs, so the trail outlives the incident [5].
The periodic entry is the one that ends up in dashboards. `UPDATE_RECOMMENDATION` carries the recommender's output: lower bound, upper bound, target, uncapped target, and a confidence value [7].
The cadence is also the cost model. One entry per minute per VPA object works out to 1,440 entries per object per day [1]. Two hundred VPA objects put 288,000 entries a day into Cloud Logging before anything is evicted at all [2]. Volume tracks how many VPA objects exist, not how much rightsizing happens. A recommendation log is a heartbeat. Heartbeats bill.
Google's post frames VPA logs alongside existing HPA logging as complete visibility across horizontal and vertical scaling [15]. The accurate version of that sentence is that visibility is now complete across two controllers. For the number to transfer to your postmortems, one thing has to be true that the announcement does not settle: the explanatory text on a failed in-place resize has to name what blocked it, not merely that the operation did not succeed. The documented example of a useful reason string is the success path, where it tells you the applied values were capped by a resource policy or an Autopilot compute ratio [11]. Failure reasons are where the morning-after value sits, and public preview [1] is where you find out how specific they are.
Test it deliberately. Set a VPA to `InPlaceOrRecreate`, schedule the pod onto a node with no headroom, force a recommendation increase, and read the resulting entries. If the failure reason resolves to something a human can act on, the objection that killed vertical autoscaling in a lot of production clusters is answered, and the argument moves to logging spend. If it does not, the payoff is still a durable record that something failed, an improvement over a Kubernetes event that already expired; the explanation itself is a separate problem still to be solved.
