Skip to content
Glowo
Esc
navigateopen⌘Jpreview
On this page

Regions

Where Glowo checks from, how multi-region checks are scheduled, and how regions affect false alarms.

Glowo runs checks from these regions:

CodeLocation
vieVienna
cdgParis
lhrLondon
iadAshburn
laxLos Angeles
nrtTokyo
sinSingapore
gruSão Paulo
sydSydney

Why more than one region matters

A single-region check cannot distinguish “the service is down” from “the path between one probe and the service is down”. Transit problems, regional routing issues and localised DNS failures all look identical to one observer.

With several regions, that ambiguity disappears: if every other region sees the service and one does not, the problem is on that path — which is real information, and not usually a reason to wake anyone.

Region strategies

Strategy Behaviour
all Every selected region checks on every interval.
round_robin One region per interval, cycling through the selection in order.
random One region per interval, chosen at random.

all gives the fastest, most confident detection, and uses the most checks. It is the right default for anything customer-facing.

round_robin and random spread coverage across regions at the cost of one observation per interval. They suit lower-priority monitors where you want geographic coverage over time rather than consensus right now.

Choosing regions

Pick regions where your users are, plus one far away. Two regions on the same continent tend to share transit and fail together, which is exactly the correlation you were trying to avoid.

If your service is only reachable from certain networks, check from regions that can actually reach it — or use a push monitor driven from inside the network instead.

Status across regions

With all, Glowo aggregates the per-region results into one monitor status. Each region’s own result is kept, so a monitor’s history shows which regions saw the failure — usually the fastest way to tell a real outage from a routing problem.

Was this page helpful?