Show HN: A minimal example of why reactive systems oscillate

I kept seeing the same failure pattern across systems that look unrelated on the surface: autoscaling that flaps, alert storms that resolve on their own, retraining pipelines that chase noise, and failover logic that makes things worse before they get better.

In each case, nothing was obviously “wrong.” The metrics were real. The thresholds made sense. The logic was locally defensible. What broke was timing.

To make this concrete, I built a tiny toy system with a feedback loop. It reacts immediately to a noisy signal by taking action, and that action feeds back into the signal. There’s no bug in the logic, just immediacy.

Conceptually, it looks like this:

signal = noisy_input() if signal > threshold: take_action()

When this runs inside a feedback loop, the system oscillates. Not because the threshold is bad, but because the decision happens before the signal has stabilized.

Now add one constraint: the decision is only allowed to exist if the condition persists over time.

window = recent(signal, N) if mean(window) > threshold and variance(window) < limit: take_action()

No prediction, no learning, no global state. Just persistence.

The oscillation disappears.

What surprised me is how often this shows up in real systems. Treating decision timing as an architectural concern, rather than a tuning problem, seems to explain a lot of brittle behavior I’ve seen in production.

I’m curious how others here handle this in practice. Do you rely on hysteresis, persistence windows, explicit “not-yet” states, or something else entirely? And where have you found immediate reaction to actually be the right choice?