Glossary
Multi-location monitoring
Multi-location monitoring is running the same check from several independent networks and declaring an outage only when enough of them agree.
Also called Multi-region checks, Quorum checks, Probe agreement, Monitoring from multiple locations.
Multi-location monitoring runs the same check from several independent networks. Its purpose is to answer the question a single check cannot: when a probe fails, was the service down, or was the path to it broken? One vantage cannot tell those apart. Several can, because a real outage fails everywhere at once and a network problem fails in one place.
The rule applied to the results is usually called quorum or probe agreement: declare an outage only when enough locations agree. It is a plain trade. Requiring agreement removes most single-network false alarms, but it costs detection time, because the outage is not declared until enough locations have checked. It can also hide a real regional failure, where customers in one country cannot reach you but the majority verdict says everything is fine.
Agreement is not the only defense against a false alarm, and the alternatives are worth knowing because they are cheaper and combine well. Requiring several failed checks in a row before declaring removes blips at the cost of one interval per extra check. Re-running a failing check straight away catches brief trouble in seconds. And a prober that tests its own connection before trusting a failure can discard a check it has reason to doubt, rather than acting on it.
| Defense | What it catches | What it costs |
|---|---|---|
| Quorum across networks | A failure on one network path while the service is up | Waits for enough networks to check, and can outvote a real regional outage |
| Several failed checks in a row | One-off blips that clear by the next check | One check interval of delay for each extra check required |
| An immediate re-check | Brief trouble that clears within seconds | A few seconds per failure, and it misses a longer network problem |
| A prober that tests its own connection | Failures caused by the prober's own network | A discarded check leaves a gap in the history rather than a result |
Questions
What is multi-location monitoring?
It is running the same uptime check from several independent networks and declaring an outage only when enough of them see it. That separates a service that is down from a network path that is broken.
Why monitor from several locations?
Monitoring from several locations tells a real outage apart from a problem on one network path. A service that is down fails everywhere, while a broken route fails in one place. It also shows whether customers in one region cannot reach you.
How many locations should confirm an outage?
There is no single right number. More agreeing locations means fewer false alarms but a later alert, and a higher bar can outvote a real regional outage. Pick a rule, then review it after a few weeks against the alerts it raised and the ones it missed.
Can multi-location monitoring miss a regional outage?
Yes. If the rule needs most locations to agree, an outage that affects one region can be outvoted, even though customers there cannot reach you. Alerting on each region separately, as well as on the overall verdict, avoids this.
Is there an alternative to checking from several locations?
Yes, and the alternatives combine well. Requiring several failed checks in a row, re-checking a failure straight away, and having the prober test its own connection all cut false alarms from one network. None of them shows how the service looks from somewhere else.
In Uptimely
Uptimely probes from one vantage today. Instead of quorum it uses time-based defenses: a check that would move a monitor to a worse status is re-run once before it counts, an incident is declared only after consecutive failed checks (two by default, configurable from one to ten per monitor), and a failure whose shape suggests the prober's own network is discarded as inconclusive rather than reported as an outage. That is a real difference from products that run each check from several networks.
Uptimely checks from one vantage and re-checks a failing result once before it counts. An incident waits for 2 consecutive failed checks by default.
Start monitoring free →Related terms
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.