What is Alert debouncing?

A monitoring system observes a condition repeatedly. A geofence checks every incoming position; an uptime monitor checks every thirty seconds. If the system notifies on every observation where the condition is bad, one real problem produces a stream of identical alerts until it is fixed.

Debouncing is the rule that turns that stream back into a single event.

The naive version and why it fails

The obvious implementation compares each observation to the previous one and alerts on change:

if (wasInside && !isInside) sendExitAlert()

This looks correct and behaves badly. The problem is that isInside is derived from a noisy measurement. With GPS drift moving reported positions by tens of metres, a stationary device near a boundary flips between inside and outside repeatedly. Each flip satisfies the condition above. The user gets an alert every few minutes from something that never moved.

Worse, the failure is silent during development. Test it by walking across a boundary once and it works perfectly. The problem only appears when a real device sits near a real boundary for a real afternoon.

The fix: separate physical state from notification state

The insight is that “where the device is” and “whether we have told the user” are two different facts, and conflating them is the bug.

Track them separately:

• Physical state — is the device inside the zone right now? Updated on every position, always accurate.
• Notification state — have we already alerted about the current excursion? Changes far less often.

Notifications fire on transitions of the notification state, not the physical one.

What Geoblip does

Every device-zone pairing carries an alertStatus of either ok or alerting, stored alongside — but independent from — the physical isInside flag.

Current status	Event	New status	Notification
ok	Device exits zone	alerting	Exit alert sent
alerting	Device exits again (drift or real)	alerting	Suppressed
alerting	Device re-enters zone	ok	Recovery sent
ok	Device re-enters zone	ok	None — was not alerting
alerting	Schedule window closes	ok	Schedule-end sent
any	Position arrives outside schedule window	unchanged	None

The rule is one line: an exit notification is sent only on the ok → alerting transition. Everything else follows.

The consequence that matters: getting a second exit alert requires a complete alerting → ok → alerting cycle. The device must genuinely re-enter the zone and then leave it again. GPS drift produces small oscillations right at the boundary and cannot complete that cycle, because re-entering properly means moving meaningfully back inside. Real movement completes it easily.

The schedule-end case

There is one situation the state machine cannot resolve on its own. If a device leaves the zone and the monitoring window closes while it is still outside, the status would be stuck at alerting forever — and the next morning’s genuine exit would be suppressed, because the transition from ok never happens.

Geoblip runs a background job every five minutes that finds pairings still in alerting whose schedule window has closed, sends a schedule-end notification, and resets them to ok. The next window therefore starts clean, and a real exit the following day alerts correctly.

This kind of edge case is where debouncing implementations usually break. The happy path is easy; the states you can get stuck in are not.

Debouncing is not rate limiting

These solve different problems and are often confused.

Rate limiting caps how many notifications go out in a time window — at most one per hour, say. It is blunt: it will also suppress a genuinely different event that happens to arrive during the cooldown.

Debouncing is state-aware. It suppresses repeats of the condition that is already active, while a different condition, or a genuine recurrence after resolution, still gets through.

For geofencing you want debouncing. Rate limiting a geofence means that if a device leaves, returns, and leaves again within the cooldown, you never hear about the second departure — which may be the one that mattered.

See also geofence hysteresis for the geometric approach to the same problem, and recovery alert for what the notification state makes possible.

Last reviewed 7 August 2026.