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 checker 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
Checker 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 checker 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 recorded response. To collect your own observation, run the checker and use its Download result JSON button.
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.
Saved observations and last up/down markers
Each service page retains up to 720 saved checks. Each contains the hostname, timestamp, verdict and reachable-region counts. There is no fixed expiry for this list; the oldest entry is removed when the limit is reached. Repeated checks with the same verdict are limited to one saved observation per five minutes per outcome. Last-up and last-down timestamps are retained separately. No recorded down observation does not prove that a service has never failed.
The history chart plots the saved observations without filling the gaps or calculating an uptime percentage. We do not retain historical response times. The global recent-check feed holds up to 1,000 entries; a separate outage feed retains up to 10,000 down observations within a rolling seven-day read window. Existing older data may be incomplete, particularly before that separate feed was introduced.
Longer history without continuous monitoring
New saved observations also contribute to hourly summaries retained for 90 days and daily summaries retained for 730 days. These contain counts of observed Up, Down and Mixed results, region counts and, where available, measured HTTP probe-duration statistics. Older saved observations remain a partial archive rather than being presented as a complete monitoring history.
A service page shows six recent records and automatically loads the cached 24-hour graph. Longer periods become selectable when older saved measurements are available. Short-period summaries are cached for several minutes; long-period summaries can be cached longer. A current live result may therefore be newer than the saved graph. Missing time periods stay empty and no uptime percentage is inferred from them.
Community reports: what visitors experience
Service pages let visitors submit “Works for me” in one click, or select a problem type in two clicks. We show working and problem totals separately, a graph of problem reports and the three most reported problem types. These are visitor contributions, not verified incidents or unique affected people. They do not change the automated checker verdict.
The view includes the current 15-minute interval and the previous 95 intervals, covering between 23 hours 45 minutes and 24 hours of elapsed time. The displayed start and update times identify the actual window; the current interval is incomplete. Problem percentages exclude working reports. Zero reports means we have no accepted contributions in that window; it does not establish that a service works for everyone.
We also save hourly community totals for a 90-day history window and daily totals for a 730-day window, keeping working reports and the individual problem categories separate. These compact totals support future historical graphs without retaining individual reports or loading that longer history on every page visit. Collection starts with accepted reports after this storage feature is enabled; missing earlier periods cannot be reconstructed. Community totals remain distinct from the technical observations in Recorded check history, even if both are shown together in a future view.
To limit repeat contributions, we accept one report per network per service every 30 minutes, with an additional limit across services. People sharing a network may share a limit. Network hashes and quota records expire; our privacy policy explains storage and retention. Reports are not forwarded to the provider; use the official help links when you need support.
Public summaries are cached, so another visitor’s figures can take up to about a minute to include a new report. The snapshot timestamp remains visible. After a successful submission, the submitting visitor receives updated counts immediately. The widget loads when visible and does not poll in the background. If the reporting service is unavailable, we show that state instead of presenting it as zero reports.