Updated 2026-07-03
"Flapping" is when a check bounces between up and down repeatedly instead of settling into one state. It's noisy and it usually has one of two causes.
The target really is unstable
Sometimes flapping is accurate — the target genuinely is intermittently failing (a backend under load, a flaky upstream dependency, a service restarting in a crash loop). In this case the flapping is the signal, and it's worth investigating the target itself rather than the monitoring configuration.
The confirmation threshold is too sensitive
If a check only requires one region to agree before going down
(confirmations: 1), any single region's transient blip immediately flips
the check, even if nothing is actually wrong with the target. Raising the
confirmation count (see How multi-region confirmation
works) means an incident only
opens once multiple independent regions agree, which filters out exactly
this kind of noise.
Smoothing with an alert delay
If you want the check itself to be sensitive (react quickly to real problems) but don't want every brief confirmed failure to notify you immediately, add an alert delay to the check's policy — Status waits a short period after confirmation before sending the first alert, so a failure that clears on its own within that window never pages you at all.
Distinguishing flapping from a slow degradation
A check can also be configured to alert on response time degradation — when recent response times exceed a threshold for several consecutive runs — which is a different signal from flapping between up and down. If what you're seeing is consistently slow rather than alternating up/down, that's a response-time threshold worth tuning rather than a confirmation setting.