How to Monitor Uptime From Multiple Locations and Compare Results

A site can appear down in one region and up in another because each check travels a different path across the internet, and any hop on that path can fail or be slow. Multi location uptime monitoring exists to separate a real outage from a routing problem, a regional DNS answer, or a single probe's bad network, so you test the same host from several vantage points and compare what each one saw.

What a multi location uptime monitoring check actually measures

Most uptime checks are one of a few protocols. An ICMP ping tells you whether a host answers at the IP layer, but many providers rate limit or block it, so a failed ping is weak evidence. A TCP connect check to a port such as 443 tells you whether something is listening and reachable. An HTTP or HTTPS check goes further: it completes a TLS handshake, sends a request, and reads the response status and body. For a website, the HTTP check is usually the one you care about, because it is the closest thing to what a visitor experiences.

The probe records more than up or down. It captures the DNS answer it received, the IP it connected to, the time to first byte, the total response time, the TLS certificate details, and the response status code. When a site is down in one place and up in another, those fields are what let you find the difference. The same hostname resolving to different IPs across regions is normal for anycast and for CDNs. A probe that resolves to a stale or unhealthy edge node will report a failure while other probes report success.

Why results differ between locations

DNS is the first place divergence appears. Resolvers in different networks get different answers, and those answers have TTL values that control how long they are cached. If you change a record and one resolver holds the old answer, probes behind that resolver keep hitting the old address until the cache expires. A single location check would show you a problem you cannot reproduce anywhere else.

Routing is the second. The path from a probe to your server is chosen by BGP, and a path can be broken or congested on one route while another is fine. You can see the path a given probe would take with a trace. Run it from a machine in the region you care about, not from your laptop:

$ traceroute -T -p 443 example.com
traceroute to example.com (203.0.113.10), 30 hops max, 60 byte packets
 1  gateway (192.0.2.1)  0.412 ms
 2  isp-edge (198.51.100.1)  3.118 ms
 3  * * *
 4  transit-a (203.0.113.1)  14.902 ms
 5  example.com (203.0.113.10)  15.331 ms

The -T flag uses TCP SYN probes rather than ICMP, which is more likely to survive filtering, and -p 443 targets the same port your users hit. A run that stalls at hop three from one location and completes from another is your answer: the failure is on the network path, not on your server.

The third source of divergence is the probe's own environment. A probe behind a corporate proxy, a congested consumer link, or a resolver with aggressive filtering can fail a check that is perfectly healthy elsewhere. This is why you want enough locations that one bad vantage point is visibly an outlier rather than the whole picture.

Configuring checks from several vantage points

Whatever tool you use, the configuration has the same shape: a target, a protocol, an interval, a timeout, and a list of locations. A minimal HTTP check definition looks like this:

type: http
url: https://example.com/health
method: GET
interval: 60s
timeout: 10s
expect_status: 200
expect_body: "ok"
locations:
  - us-east
  - eu-west
  - ap-southeast

Two settings matter more than people expect. The timeout must be longer than the slowest legitimate response from the slowest location, or you will generate false alarms from far away probes. And the expected body should be a short string that only appears on a healthy response, not the whole page, so that a valid but empty page does not pass.

Send a request by hand to understand what the probe sees. The -I flag sends a HEAD request and prints response headers, which is faster than downloading the body:

$ curl -sSI https://example.com/health
HTTP/2 200
content-type: text/plain
cache-control: no-store
server: nginx

If your health endpoint sits behind a cache, add cache-control: no-store on the response, otherwise a probe in one region may read a cached success while another reads a real failure. If you run the check against a hostname that resolves differently per region, confirm the resolution each probe gets by querying a public resolver directly with dig and comparing the answers:

$ dig +short example.com @198.51.100.53
203.0.113.10
203.0.113.11

Different answers from different resolvers are expected. What you are looking for is a probe that resolves to an address no other probe uses, which usually means a stale cache or a misconfigured record.

Interpreting the comparison without panicking

One location failing while the rest pass is almost never a server outage. It is a path problem, a resolver problem, or a probe problem. Two or more locations failing at the same moment, especially in different networks, points at your origin. All locations failing points at your origin or your DNS, and you should confirm from a machine you control before you start changing anything.

Look at the timing as well as the status. If every location reports a slow response but none fail, you have a capacity or latency problem, not an outage. If failures cluster in one region and clear after a few minutes, a route changed and recovered. Alerting on a single failed check from a single location produces noise; alerting when a majority of locations fail produces signal. Set your alert rule to require agreement across locations, and keep the per location history so you can see the pattern later.

Also compare what the probe measured against what a real user would see. A check that only fetches /health can pass while the pages users actually load fail, because the health endpoint may not touch the database or the cache. Add a second check against a real page if the health endpoint is shallow.

What to do next

Pick three locations that match where your users actually are, not three that are convenient. Start with HTTP checks against a real page, set the timeout from your slowest observed response, and alert only when several locations agree. Keep the per location response times and DNS answers in your monitoring history so that the next time someone reports the site is down, you can say which regions saw it and which did not, and point at the hop or the resolver that explains the difference.