Multi-region HTTP/HTTPS connectivity test — verify uptime and response times worldwide
Monitor continuously
Create a scheduled monitor — automatically probe from multiple global nodes and get alerted on failures.
• Target: full HTTP/HTTPS URL (e.g. https://example.com)
• Method: choose GET, POST, or HEAD
• Redirect: whether to follow 3xx responses automatically
• Nodes: pick specific nodes; defaults to all available nodes
An HTTP/HTTPS check sends real requests to your URL from multiple nodes worldwide and returns each region's HTTP status code, response time, and success state. Because it verifies availability at the application layer, it reflects the real user experience better than ping alone.
Typical scenarios include monitoring availability and speed across regions, confirming a deployment or CDN switch has taken effect globally, and investigating pages that fail to load in certain regions. GET/POST/HEAD and redirect following are supported.
Ping uses ICMP to measure network-layer connectivity and latency; an HTTP check sends a real HTTP request and measures whether the web service responds correctly and how long it takes. When a site won't load, the HTTP check reflects reality better.
It generally covers DNS resolution, TCP connect, the TLS handshake, and receiving the response. When one region is clearly slower, combine it with multi-location ping and traceroute to tell whether the bottleneck is resolution, the link, or the server.
The check only validates the HTTP status and response time; it does not render page content. A 200 means the server responded normally — if the content is wrong, inspect your application logs; it is unrelated to the network path.
Run the check from several nodes at once and compare status codes and response times. If a single region fails or times out while others are fine, it is usually a link or regional reachability issue between that region and your server.