It was still dark when Man, the new hand at the bathhouse on the south side of town, took over the morning shift.

The owner left him with one instruction: “Keep the pool comfortable. They’ll curse you if it’s cold. They’ll curse you if it’s scalding.”

In the corner stood an iron stove, its flue running under the floor of the pool. Add coal, the water heats. Open the windows, the heat escapes. Simple enough.

At a quarter past five, the first bathers climbed in and cried out in unison that it was freezing. Man hurried over and shoveled three loads of coal into the stove. The fire went up with a roar.

He waited. The water was still cold.

He waited a while longer. Still cold. The bathers began slapping the stone rim and complaining. Man set his jaw and shoveled in three more.

Half an hour later, the pool boiled. Truly boiled — steam swallowed the roof beams, red-faced men leapt out of the water, and the cursing was worse than before.

Man panicked, grabbed a bamboo pole, and threw all four shutters open. Cold air poured in. Fifteen minutes later a thin mist lay on the surface and the bathers were shouting about the cold again. So he shoveled coal. Then opened windows. Then shoveled coal.

By midday he had made seventeen trips, was soaked with sweat, and the pool had not been comfortable for a single moment. It was either scalding or freezing, like a swing shoved by two hands in turn — and the harder they shoved, the wider it swung.

Only then did the old master come strolling in from the back courtyard. He took one look, and sat down.

“Have you noticed,” he said, “that the coal you shovel doesn’t reach the water for half an hour?”

“I know. That’s exactly why I can’t wait.”

“You can’t wait because you’re talking to the water as it is now. But the water is answering what you said half an hour ago. The two of you aren’t even in the same hour.”

The old master had a wooden temperature gauge hung by the pool, then laid down three rules and had them written on the wall.

First: don’t look at this instant’s water. Look at the average over the last half hour. Someone jumping in brings a swirl of cold with him. That doesn’t count.

Second: cold does not always mean coal, and hot does not always mean windows. Add coal only below thirty-eight degrees. Open windows only above forty-two. Between thirty-eight and forty-two — do nothing at all, no matter how wrong it feels to your hand. That band belongs to the stove, so it can finish walking the half hour it’s already walking.

Third: one shovel at a time. Then sit down, count out a full half hour, and only then decide the next move. Even while they’re cursing you.

Man did as he was told. For the first two hours he felt like a loafer, sitting there doing nothing. But by the afternoon something strange had happened: he had added four shovels of coal the entire day, opened the windows once, and the pool had been warm from dawn to dusk.

The needle on that wooden gauge had barely moved.

— By now you’ve probably recognized it: this isn’t a story about a bathhouse. It’s a story about a feedback control loop. Man’s seventeen trips are the autoscaler flapping that every SRE has watched happen: because there is a delay between action and effect, the controller oscillates endlessly between overshoot and undershoot. The old master’s three rules are metric smoothing, hysteresis, and a stabilization window.

What this is

Any closed loop of “measure → decide → act” risks oscillation the moment there is delay between acting and observing the result. Control theory calls it dead time: the longer the delay and the higher the gain, the more easily a system slides from convergence into self-sustained oscillation.

Kubernetes’ HorizontalPodAutoscaler is the canonical example. It sees CPU high and scales up — but the new Pods must pull an image, start, pass readiness probes, and get admitted into the Service endpoints, which can take a minute or two. Throughout that window the metric is still high, so the controller keeps scaling; by the time all the Pods are finally up, capacity has badly overshot. The metric then collapses, the controller scales down, traffic arrives, and there isn’t enough again. That is Man’s swing.

The cure is not to make the controller smarter. It is to make the controller slower — deliberately, in four specific ways:

• Metric smoothing. Use an aggregate over a window, not an instantaneous sample. HPA reads an averaged value over the metrics-server scrape window precisely so that a single spike can’t yank it around.
• Hysteresis / deadband. Use different trigger points going up and going down, with a dead zone between them. In HPA this is --horizontal-pod-autoscaler-tolerance (10% by default): if the ratio of desired to current replicas falls between 0.9 and 1.1, the controller does nothing. Without that band, a metric jittering around a single threshold fires the loop over and over.
• Stabilization window. behavior.scaleDown.stabilizationWindowSeconds defaults to 300 seconds, during which HPA takes the maximum of its recent recommendations — effectively demanding five straight minutes of calm before it will shrink. The scale-up window defaults to zero, because the cost of being overloaded usually dwarfs the cost of a few extra Pods: the two directions were never meant to be equally cautious.
• Rate limit / step size. The policies under behavior cap how many Pods (or what percentage) may be added or removed per period. One small step at a time is safer than jumping all the way.

None of this belongs to HPA alone. Cluster Autoscaler’s scale-down-unneeded-time, BGP route flap damping, the deliberate asymmetry of additive-increase/multiplicative-decrease in TCP congestion control, the couple of degrees of swing built into your thermostat, even the pace at which you resize a team — all the same problem, all the same answer: when feedback is delayed, the best reaction speed is not the fastest one.

And there is a deeper lesson under it. Rather than endlessly tuning parameters to suppress the oscillation, first shorten the delay itself. Smaller images, faster startup, earlier readiness, tighter scrape intervals. The shorter the loop, the faster you can safely react. Tuning finds the optimum under a given delay; shortening the delay raises the optimum.

Metaphor mapping

• The water temperature → the observed metric (CPU, QPS, queue depth)
• Man → the controller (HPA, Cluster Autoscaler, any reconcile loop)
• Shoveling coal / opening windows → scale up / scale down
• The half hour between coal and warmth → dead time: Pod startup + readiness + metrics scrape interval
• “You talk to the water now, it answers what you said half an hour ago” → the controller always sees a past state of the system
• Seventeen trips, a swing widening with every shove → oscillation / flapping
• Bathers leaping out scalded → overshoot: wasted capacity and harmed users
• “Look at the average over the last half hour” → metric smoothing, the aggregation window
• Thirty-eight and forty-two as two separate thresholds → hysteresis, different trigger points per direction
• Doing nothing between thirty-eight and forty-two → deadband / HPA tolerance
• “Shovel, then sit and count out a full half hour” → stabilization window (300s by default on scale-down)
• “One shovel at a time” → rate limit / step size in scaling policies
• The old master’s stillness → in a delayed loop, restraint is itself a correct control strategy
• Four shovels all day, and the water always warm → convergence: fewer actions, steadier results