One hostname, from eight configured locations
A normal check requests the origin of the address you enter. For https://example.com/account?view=orders, that means https://example.com. The path, query and fragment are not tested. A successful origin response therefore says nothing about that particular account page.
We configure eight Vercel probe locations: US East (IAD), US West (SFO), Paris (CDG), Frankfurt (FRA), Singapore (SIN), Tokyo (HND), Sydney (SYD) and São Paulo (GRU). These are locations within one hosting provider, not eight independent monitoring companies or residential networks. Location labels describe the configured endpoints; they do not independently establish the physical path taken by every request.
A probe starts with an HTTP HEAD request and follows redirects. If it receives 403 or 405, it tries GET with Range: bytes=0-0. Each HTTP attempt has a 7.5-second timeout. A server may ignore the range header. We do not execute page JavaScript, sign in, add products to a cart or complete transactions. HTTP method semantics are documented in RFC 9110.
How the current rules classify results
The API first excludes probe endpoints that could not return a usable result. The majority is more than half of the remaining results. Inspect the coverage count: one usable result and seven unavailable probes gives much less evidence than eight usable results. The confidence label describes agreement between available probes; it is not a measured probability or an accuracy percentage.
| Signal | Result and interpretation |
|---|---|
| A majority receives a final response below 500 | Up: the host responded. This includes 403, 404 and 429, which can still prevent a visitor from using it. |
| A majority is classified as DNS unreachable | Down (DNS): our diagnostic resolvers did not provide usable address answers. This does not identify the underlying DNS cause. |
| No successful responses; a majority returns 5xx | Down (5xx): the requested origin returned server errors. |
| No successful responses; a majority times out | Mixed: the coordinator requests another pass. Persistent timeouts remain unconfirmed; they can reflect filtering or a network failure. |
| Filtering signals, partial success or insufficient evidence | Mixed: compare the individual responses, your browser and the provider’s incident information. |
After some all-failure results we also check the corresponding www or non-www hostname. A responding alternate changes the result to Mixed. Persistent timeouts and likely filtering skip this alternate-host step. An alternate is a separate hostname, not proof that the original hostname works.
What happens after a failed request
The probe asks Google Public DNS and Cloudflare DNS for A and AAAA records and requests two control URLs. If DNS resolves and a control responds but the target connection fails, the current rule can label it “likely filtered”. That is a hypothesis: a TLS or target-specific connection problem can produce the same combination. Our DNS guide explains how to examine the individual answers.
Time, retries and caching
API and regional responses are configured for a 30-second shared cache with a 60-second stale-while-revalidate window. The top-level checkedAt records when the result was assembled; each region has its own observation timestamp. A quick recheck can reuse a cached response. Even the coordinator’s second pass may retrieve the same cached regional observation, so it is not necessarily an independent repeat measurement.
The displayed overall response time is the time spent assembling the check, including coordination and diagnostics. It is not browser page-load time or a geographic latency benchmark. For a comparison, inspect each region’s timestamp and duration separately.
A recorded check you can inspect
On , our public endpoint returned eight HTTP 200 responses for https://example.com. The API classified the result as Up. The overall duration was 1,279 ms. This is one successful demonstration using a documentation domain, not a test of outage-detection accuracy.
| Configured location | HTTP | Probe duration | Observed at (UTC) |
|---|---|---|---|
| US East | 200 | 28 ms | 13:18:48.334 |
| US West | 200 | 297 ms | 13:18:48.652 |
| Paris | 200 | 351 ms | 13:18:48.637 |
| Frankfurt | 200 | 401 ms | 13:18:48.653 |
| Singapore | 200 | 988 ms | 13:18:49.321 |
| Tokyo | 200 | 754 ms | 13:18:49.130 |
| Sydney | 200 | 947 ms | 13:18:49.345 |
| São Paulo | 200 | 526 ms | 13:18:48.904 |
Download the original API response. To make your own observation, run the check or request:
curl --max-time 70 'https://websitedown.org/api/check?url=example.com'The response may change. Compare the timestamps before counting two responses as separate observations. The disagreement guide shows what to do when the result differs from your browser.
What a check cannot establish
- A responding homepage cannot confirm login, checkout, search, video playback or API operations.
- Eight configured locations cannot establish availability on every ISP, country or device.
- Recent public checks are visitor-triggered samples. They are not continuous monitoring, outage duration or an uptime percentage.
- Repeated failures are not a provider-confirmed incident. Consult a provider’s own status updates and your own telemetry.
- A missing regional result is a gap in evidence, not a failed response from the target website.
Documentation was checked against the implementation on 7 September 2026. Publish corrections through our contact page; see the editorial policy for how sources and AI assistance are handled.