Regions
Where Glowo checks from, how multi-region checks are scheduled, and how regions affect false alarms.
Glowo runs checks from these regions:
| Code | Location |
|---|---|
vie | Vienna |
cdg | Paris |
lhr | London |
iad | Ashburn |
lax | Los Angeles |
nrt | Tokyo |
sin | Singapore |
gru | São Paulo |
syd | Sydney |
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.