About Website Availability & Latency Checker
Website Availability & Latency Checker sends the same GET request to one URL from a group of remote probe regions and streams each regional result back as it lands. For every region you get reachability, the HTTP status, the negotiated protocol, the share of samples that succeeded, and a stage-by-stage timing breakdown covering DNS, TCP, TLS, and time to first byte.
"The site is down" is almost never a global statement. A site can be unreachable from one country and healthy everywhere else because a CDN node is unhealthy, a regional DNS answer points at the wrong address, a transit provider is having a bad day, or a firewall blocks a range. Checking from your own location cannot distinguish any of these from a real outage. The other half of the problem is that failures have a stage: DNS resolving, TCP opening, TLS completing, and the first byte arriving are four separate events, and knowing which one stopped tells you which team to talk to.
How to use this developer tool
- Enter the exact URL including the scheme. Test the final URL rather than a shortener or a redirecting hostname, so the result describes the page and not the redirect.
- Choose the region group that matches the audience or the incident — a global spread for a broad picture, or one continent when you know where the complaints came from.
- Run the check and watch results stream in per country; each row appears as its region finishes, so a slow region does not hold back the rest.
- Read status and timing together. A 200 with a 3000 ms time to first byte is a different problem from a 200 at 120 ms, and both differ from a timeout.
- Re-run before drawing a conclusion. A single failed sample is one failed request, not proof that every visitor in that country is affected.
Worked example: a regional edge problem
A global spread against a site that is healthy almost everywhere. One region's numbers make the shape of the problem obvious in a way a single check from your own machine never could.
URL https://example.com
Region Global representative exits8/8 regions completed · 7 reachable · 1 failed · average 214 ms
Europe
DE 200 h2 3/3 samples dns 4 ms · tcp 11 ms · tls 22 ms · ttfb 48 ms
GB 200 h2 3/3 samples dns 6 ms · tcp 14 ms · tls 28 ms · ttfb 61 ms
North America
US 200 h2 3/3 samples dns 8 ms · tcp 23 ms · tls 47 ms · ttfb 96 ms
Asia
JP 200 h2 3/3 samples dns 12 ms · tcp 38 ms · tls 79 ms · ttfb 152 ms
SG 200 h2 2/3 samples dns 14 ms · tcp 41 ms · tls 88 ms · ttfb 940 ms
IN — — 0/3 samples PROBE_TIMEOUTThree states are visible. Germany, the UK, the US, and Japan are healthy. Singapore completed two of three samples with a time to first byte an order of magnitude above its TLS time, so the connection is fine and the response is slow — an origin or cache problem. India returned nothing within the timeout, which points at routing or filtering rather than the application.
What each response class means for a reachability check
The distinction that matters most is between any status code and no status code at all.
| Result | What the probe observed | What it tells you |
|---|---|---|
| 2xx | A complete response with a success status | The path works end to end. It says nothing about whether the page content is correct. |
| 3xx | A redirect response | The server answered, but not with the page. Test the final URL, or you are measuring the redirect hop. |
| 401 / 403 | The server refused the request | The path works and the application rejected this client. On a public URL this is usually bot protection reacting to a datacentre address. |
| 404 / 410 | The resource is absent | Reachability is fine and the URL is wrong — a useful negative, because the infrastructure is healthy. |
| 429 | Rate limited | The origin or its CDN is throttling. Repeating the check makes this worse, not clearer. |
| 5xx | The server failed to produce a response | The network reached the application and the application broke. The one class pointing squarely at your own stack. |
| Timeout (no status) | Nothing arrived before the deadline | Categorically different from any status code: routing, a firewall, a dropped path, or an origin that never replied. There is no server-side signal to interpret. |
| DNS or TLS failure | The connection never got as far as a request | The stage names the layer: an unresolved name, a rejected certificate, or a handshake that could not complete from that region. |
Troubleshooting
The site loads fine in your browser but every region returns 403.
Why it happens Bot protection. WAFs and CDN security products score datacentre ranges harshly and expect browser signals — a full header set, a TLS fingerprint, sometimes a JavaScript challenge — that a probe does not produce.
Fix This is a correct result about real behaviour. If you control the site, allow-list the probe behaviour or test an endpoint outside the protected path, such as a health check URL.
The check reports a 3xx while the browser shows the page.
Why it happens The browser follows redirects silently, so you never see the hop. The probe reports the response it actually received.
Fix Enter the final URL — canonical host, correct scheme, with or without www. If you cannot get past it, you likely have a loop between http and https or apex and www, which shows up as repeated redirects or a timeout.
One region fails while every other region succeeds.
Why it happens Regional DNS returning a different address, an unhealthy CDN node, a peering or transit problem, or a firewall blocking a range. All four look identical from outside.
Fix Read the failure stage: DNS means the name did not resolve there, a connect failure or timeout means the address was unreachable, TLS means a wrong certificate or an intercepting middlebox. Re-run to confirm before changing anything.
The check stops working partway through the day.
Why it happens The allowance is 10 checks per visiting IP per UTC day, shared by everyone behind the same public address, because each check generates real requests to a third-party server.
Fix Plan the checks: one URL and one region group per attempt rather than exploring. For ongoing visibility use a monitoring service you have authorised to poll continuously.
Latency looks far worse than users report.
Why it happens Each probe opens a cold connection: a full DNS lookup, a new TCP handshake, and a complete TLS negotiation with no session resumption. Real visitors reuse connections and hit warm caches.
Fix Compare the stage breakdown rather than the total. Time to first byte is closest to what a returning visitor experiences; DNS, TCP, and TLS are one-time costs a real session amortises.
Every region returns 200 but users still report a broken site.
Why it happens A reachability check requests one URL and reads the status. It does not execute JavaScript, load subresources, or verify that the page rendered.
Fix Treat a green result as a statement about the network and the origin's front door only. Broken assets or a failing API call need browser-level testing or your own application logs.
When this tool is the right choice
- Deciding whether an outage report is global or confined to one region, before waking anyone up.
- Confirming that a DNS change, a CDN configuration, or a certificate renewal has taken effect outside your own network.
- Finding which stage is slow — DNS, TCP, TLS, or the application — instead of guessing from one total figure.
- Checking that a newly launched endpoint is reachable from the continents your users are on.
When to use something else
- Continuous monitoring or alerting. This is a snapshot with a small daily allowance; use a monitoring service you have authorised to poll on a schedule.
- Testing a site through a specific proxy. Regional Proxy Exit Check routes the request through a proxy you supply and reports what the target saw.
- Auditing page content, links, accessibility, or security. It reads the response status, not the page, and it does not crawl.
Privacy and data handling
The URL and your chosen settings are sent to this site's server so the remote probes can make the request on your behalf. Each probe then contacts the target directly from its own region, so the target sees a request from that region's address and may log it like any other visitor. Because the URL travels to our server and is requested by a third-party network, never submit an admin panel, a signed or pre-authenticated link, a URL containing an access token, or an internal hostname. The check is limited to 10 checks per visiting IP per UTC day, deliberately tight because every check generates real traffic to someone else's server.
Related developer tools
Frequently asked questions
Does a 200 mean the site is healthy?
It means one probe made one request to one URL and got a success status back. It does not cover other pages, logged-in flows, subresources, or API dependencies. A green row is evidence about the path and the front door only.
Why does one region fail while the others pass?
Regional DNS answers, CDN node health, peering, transit routing, and firewall rules all differ by location and can fail independently. The failure stage separates them: a DNS failure, a connection timeout, and a TLS error each implicate a different layer.
How many checks can I run?
Ten per visiting IP per UTC day. The limit is small on purpose, because every check sends real requests to a server that did not ask to be tested, and it is shared by everyone behind the same public address.
Does the checker crawl my site?
No. It requests the single URL you enter and reports the response. It follows no links, loads no images or scripts, and stores no page content.
Why is the reported latency higher than my own measurements?
Every probe starts cold — fresh DNS, a new TCP connection, a full TLS handshake — while your browser and your users reuse connections and warm caches. Compare probes against each other across regions and over time.
Can I check an internal or password-protected URL?
You should not. The URL goes to our server and is then requested by a third-party network from a public address, so an internal hostname will simply fail to resolve while a token-bearing URL would be exposed unnecessarily. Test a public health endpoint instead.
What does a success rate between 0 and 100 percent mean?
Each region takes several samples. A partial rate means some requests completed and others did not — the signature of intermittent packet loss, an unhealthy node behind a load balancer, or a rate limit engaging.