Glossary
Flapping
Flapping is when a monitor switches between up and down again and again, so every flip can send its own alert.
Also called Flapping monitor, Alert storm.
A flapping monitor is one that keeps changing its mind. It goes down, up, down and up again, and each change can send its own notification, so one unstable service produces a stream of pages that contradict each other. That is worse than a steady outage. An outage sends one clear message, while flapping alerts send many that each cancel the last, and the responder ends up debugging the monitoring instead of the service.
Service flapping has real and artificial causes. Real flapping means the service is genuinely unstable: one unhealthy instance behind a load balancer failing one request in four, a resource running out and recovering in a loop, or a dependency that is itself flapping. Artificial flapping means the check is marginal. A timeout set just below the service's normal response time turns ordinary variation into a coin toss.
The standard fixes are thresholds and hysteresis. Require several failed checks in a row before declaring the service down, and optionally several passes in a row before declaring recovery, so one sample in either direction cannot move the state. Grouping related alerts into one incident helps too, because flapping often hits several monitors at once. None of that fixes the instability underneath. Damping the alert makes it survivable, not solved, and a monitor that needs heavy damping to stay quiet is telling you something.
| Six checks in a row | Status changes recorded | Incidents at a threshold of 1 | Incidents at a threshold of 2 |
|---|---|---|---|
| Down, up, down, up, down, up | 6 | 3 | 0 |
| Down, down, up, down, down, up | 4 | 2 | 2 |
| Down, down, down, down, up, up | 2 | 1 | 1 |
| Down, up, up, up, up, up | 2 | 1 | 0 |
Questions
What does flapping mean in monitoring?
It means a check keeps switching between passing and failing, so the monitor keeps changing between up and down. Each change can raise or clear an alert, which is why a flapping monitor is noisy even when nothing new is happening.
What causes a service to flap?
Either the service is unstable, for example one bad instance behind a load balancer or a resource that runs out and recovers, or the check is marginal, for example a timeout set just below the service's normal response time.
How do you stop flapping alerts?
Require several failed checks in a row before an incident is declared, so one bad sample cannot page anyone. Then look for the cause: a check that is too tight, or a service that really is unstable. Silencing the monitor only hides it.
Should recovery also wait for several passing checks?
It is a trade-off. Waiting for several passes stops a flapping service from resolving and reopening incidents, but it keeps an incident open after the service is back, so the record says it was down for longer than it was.
Does Uptimely detect flapping monitors?
It does not mark a monitor as flapping. It damps flapping instead: an incident waits for 2 failed checks in a row by default, any passing check resets that count, and every change of status is still recorded on the monitor's timeline.
In Uptimely
Uptimely does not mark a monitor as flapping. It damps flapping instead. A result that would make a monitor's status worse is checked a second time before it counts. An incident is declared only after 2 failed checks in a row by default, adjustable from 1 to 10 per monitor, and any passing check resets that count. Recovery is immediate: the first passing check resolves the incident. Every change between up and down is still recorded on the monitor's status timeline, so damping the alert never hides the flapping itself.
Uptimely waits for 2 failed checks in a row before it declares an incident, resets that count on any passing check, and resolves on the first check that passes.
Start monitoring free →Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.