Global Watch Network
Your monitoring says “all clear” because it only checks from one place. Pulse Stack checks from 10+ locations simultaneously so regional outages, CDN failures, and routing problems never go unnoticed.
NYC
32ms
SFO
45ms
YYZ
38ms
LHR
28ms
FRA
31ms
SIN
89ms
TYO
78ms
SYD
112ms
BOM
105ms
GRU
95ms
How multi-location checks work
Every time a check runs, Pulse Stack sends requests from all enabled 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 9 locations get a 200 OK and one gets a timeout, that single failure is noise. If 4 locations in Asia all fail while the rest succeed, you have a genuine regional 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 every monitor type: HTTP uptime checks, ICMP ping, TCP port scans, and API health checks all run from multiple locations by default.
False alarm elimination
The consensus algorithm adapts its verdict based on how many locations report failure and which ones. A single-location failure is almost certainly a false positive caused by a local network issue at the monitoring node. Three failures in the same region point to a CDN or routing problem.
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.
Set your own thresholds for how many locations must fail before an alert fires. 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 Frankfurt (31ms) than to Sydney (112ms). That is physics. But if London-to-Sydney 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 separate DNS resolution delays from actual server response time. Use the SLA calculator to convert uptime percentages into real downtime minutes per region.
Every monitor gets multi-location checks by default. Free for 50 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 detects CDN edge failures by comparing response times across regions. A sudden 3x latency increase from one location while 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 each region verifies that geo-DNS resolves correctly everywhere. If Frankfurt checks start routing to a US IP instead of an EU IP, the latency jump shows up immediately. Add DNS record monitoring to track the actual resolution results per region.
DNS resolution by location
Asia-Pacific resolving to US servers instead of APAC edge
Internet routing is not a single path. Traffic from Tokyo 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
50 monitors free forever. Upgrade when you need faster checks or more capacity.
Most popular
£29/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 10+ locations worldwide. Free for 50 monitors, no credit card required.
Start global monitoring free