Multi-location monitoring
Your monitoring says “all clear” because it only checks from one place. PulseStack checks from London, New York and Sydney simultaneously, so outages, CDN failures and routing problems that hit more than one region are caught, while a blip at a single location stays quiet.
NYC
32ms
LHR
28ms
SYD
105ms
How multi-location checks work
Every time a check runs, PulseStack sends requests from all three locations simultaneously. Each probe connects independently through its own network path, DNS resolver, and ISP routing. The responses come back at different speeds based on geography and network conditions.
If 2 locations get a 200 OK and one gets a timeout, that single failure is noise. If more than one location fails at the same time, you have a genuine problem. The consensus algorithm separates signal from noise automatically, which means your alert channels only fire when there is a real issue.
This works across your monitors: HTTP uptime checks, TCP ping, TCP port checks, and API health checks all run from all three locations.
False alarm elimination
The consensus algorithm adapts its verdict based on how many locations report failure. A single-location failure is almost certainly a false positive caused by a local network issue at the monitoring node. Failures from two or more locations point to a real problem, such as a CDN or routing fault.
Teams running single-location monitoring get woken up at 3am for false alarms. They start ignoring alerts. When a real outage hits, the notification sits unread in a channel full of noise. Consensus-based alerting keeps your response sharp because every alert means something.
The rule is the same on every plan: a monitor is marked down when at least two of the three locations fail, after a quick re-test. Combine with incident management to automatically create incidents when the consensus verdict changes, and push updates to your status page so customers know what is happening.
ALL CLEAR
Every location confirms your service is reachable. No action needed.
Geographic performance
A server in London naturally responds faster to checks from New York (32ms) than from Sydney (105ms). That is physics. But if the Sydney check suddenly jumps to 400ms, something changed: a routing issue, a CDN edge failure, or a provider problem that only affects traffic crossing certain network paths.
Sort by fastest or slowest to identify which regions experience the best and worst performance. Track these numbers over time through the response time dashboard to spot trends before they become outages.
If your CDN contract promises sub-100ms delivery worldwide, this data gives you the proof. Combine with DNS monitoring to confirm your records hold the values you expect. Use the SLA calculator to convert uptime percentages into real downtime minutes per region.
Every uptime monitor gets multi-location checks on every plan. Free plan covers 5 monitors.
Three real-world scenarios where checking from one place gives you a false sense of security.
Your CDN caches content at edge locations worldwide. When a CDN edge in Singapore stops serving cached content, response times spike for users in that region. But your monitoring server in Virginia sees perfectly normal performance because it hits a different edge.
Multi-location monitoring makes CDN edge problems visible: response times are charted per region, so a sudden 3x latency increase from one location while the others stay flat points directly to a cache miss or edge outage. Pair with content monitoring to verify the cached content is actually correct, not just fast.
CDN edge status
Geo-DNS routes users to the nearest server based on their location. When it misconfigures, users in Europe might hit your US servers, adding 100ms of latency. Or worse, they get routed to a server that has been decommissioned.
Monitoring from London, New York and Sydney verifies that geo-DNS resolves correctly in each region. If London checks start routing to a US IP instead of an EU IP, the latency jump shows up immediately. Add DNS record monitoring to get alerted when a record no longer holds the value you expect.
DNS resolution by location
Asia-Pacific resolving to US servers instead of APAC edge
Internet routing is not a single path. Traffic from Singapore to your London server passes through multiple autonomous systems, peering points, and undersea cables. When one link in that chain fails, only traffic from specific origins is affected. Your server looks healthy from its own network.
Multi-location monitoring reveals routing-specific failures that are invisible from your data centre. If your server responds to all locations except those routing through a specific transit provider, the pattern tells you exactly where to look. Combine with SSL certificate monitoring and TCP connection checks for full connection verification across every network path.
Connection status
5 monitors free forever. Upgrade when you need faster checks or more capacity.
£99/month
All plans include multi-location checks, incident management, and public status pages. Full plan comparison →
Multi-location monitoring works with all these monitor types.
Everything you need to know about multi-location monitoring.
Monitor from London, New York and Sydney. Free plan covers 5 monitors, no credit card required.
Start global monitoring freeNew to uptime monitoring? Our guide to uptime monitoring explains how checking from more than one location separates real outages from faults on a single network path, and monitoring locations shows how to let the checks through your firewall.