What is Geofencing?

Geofencing turns a location into an event. You define a boundary — a circle around an address, or a polygon traced around a school campus — and a system watches incoming position reports, comparing each one against that boundary. When a device moves from inside to outside, or outside to inside, something happens: a notification, a log entry, a webhook.

That is the entire concept. Everything else is detail about how the boundary is stored, how positions arrive, and how crossings are decided.

The three pieces

A working geofence needs all three. Missing any one and you have a drawing, not a system.

1. A boundary. Stored as a centre point plus a radius, or as a list of corner coordinates. See GeoJSON polygon for the format most systems use.
2. A stream of positions. From a phone app, a hardware GPS tracker, or an API. Without regular reports there is nothing to test.
3. A decision rule. Given a position and a boundary, is the device inside? This is the point-in-polygon test, and it is the easy part.

Why real geofencing is harder than it sounds

The geometry is trivial. A first-year programming exercise can tell you whether a point falls inside a polygon. What makes production geofencing difficult is that the positions lying to you.

Consumer GPS reports a position that is accurate to roughly 5–10 metres under open sky, and 30–50 metres or worse between tall buildings. A device sitting perfectly still near a boundary will report positions that scatter across it. Naively, each apparent crossing generates an alert, and the user gets twenty notifications from a phone that never moved. This is GPS drift, and handling it is most of the real engineering.

The second problem is that a crossing is often only interesting sometimes. A child leaving school grounds at 11am matters. At 4:30pm, when school ends, it does not. A geofence without a time dimension produces alerts nobody wants, which trains people to ignore the ones that count.

What Geoblip does

Geoblip addresses both directly.

Time windows are per device, per zone. The same boundary can be active 08:30–16:30 on weekdays for one device and never for another. Outside the window, positions are recorded but no alert fires.

Alerts are state-based, not event-based. Rather than notifying on every observed crossing, each device-zone pairing carries a status of either ok or alerting. An exit notification is sent only on the transition from ok to alerting. If the device is already in the alerting state and appears to exit again — real movement or GPS noise — the notification is suppressed. A fresh alert requires a complete alerting → ok → alerting cycle, meaning the device genuinely returned and left again. This is covered in alert debouncing.

That state also enables something most systems skip: a recovery alert when the device comes back, so you learn the situation resolved without having to go and check.

Common uses

• Family safety — knowing a child arrived at school, or left when they should not have
• Elderly and dementia care — alerting when someone leaves a safe area
• Fleet and field service — arrival and departure at customer sites, without manual check-ins
• Equipment and asset protection — trailers, generators, and tools leaving a yard
• Pets — a dog leaving the garden

Geofencing vs live tracking

These get conflated and they answer different questions. Live tracking shows where something is, continuously, and requires you to look. Geofencing tells you when something changed, and requires nothing from you until it matters.

Most people asking for tracking actually want geofencing. Watching a map is a task; getting a notification is not.

You can try building a boundary with the free geofence builder, or see how Geoblip works end to end.

Last reviewed 7 August 2026.