When a site loads in your browser but a script or a friend gets an error, one curl can't tell you why. isitdown.io checks every website with 4 independent probe methods in parallel, differing by HTTP version, TLS strictness, HTTP method, and User-Agent, in the same window. This is what that buys you.
The problem with a single request ¶
A single ping or curl from one client tells you one thing: whether that exact request, with that exact User-Agent, protocol, and method, got through right now. It does not distinguish:
- "Server is genuinely down for everyone" from
- "Server blocks this User-Agent but serves browsers fine" from
- "Server only speaks one HTTP version" from
- "Server rejects this method or this TLS handshake."
Plenty of "down" reports aren't outages at all. They are:
- Bot / User-Agent blocks, a WAF or Cloudflare Bot Fight Mode returns 403 to non-browser clients while real browsers load fine.
- Protocol mismatches, an origin that only speaks HTTP/1.1 (or only HTTP/2) fails clients that assume the other.
- TLS strictness, an expired or misconfigured certificate fails strict validation but connects when validation is relaxed.
- Method quirks, a server that answers GET but returns 405 to a HEAD request.
A single request can't separate these from a real outage. Four deliberately-different requests make them obvious.
The four probe methods ¶
Every /check/<domain> request kicks off four parallel probes, chosen to differ in the ways that trip sites up:
| Method | What it isolates |
|---|---|
| HTTP/1.1 · strict TLS | Baseline GET with our default User-Agent and full certificate validation. |
| HTTP/2 · relaxed TLS | Does the origin speak HTTP/2? Does it connect when cert validation is relaxed (isolating cert problems)? |
| GET · browser User-Agent | A real Chrome User-Agent. If this passes while others fail, the site is blocking non-browser clients, not down. |
| HEAD · curl User-Agent | A lightweight HEAD with a curl UA. Catches HEAD refusal (405) and aggressive anti-automation filtering. |
What 4 parallel methods reveal ¶
With all four probing in parallel, the fail count is a fast first read:
| Fail count | Interpretation |
|---|---|
| 0 / 4 | Healthy for every client type. If you can't reach it, the issue is local. |
| 1 / 4 | The site treats one request type specially, a UA block, a HEAD refusal, a cert quirk, or a missing protocol. Up, but picky. |
| 2 / 4 | Two client types rejected. Often aggressive bot filtering or a partial misconfiguration. |
| 3 / 4 | Only one method still gets through, usually the browser-UA GET. The site is barely serving anything but real browsers. |
| 4 / 4 | Confirmed outage. No client type gets a successful response. |
That's a four-bit diagnostic before you've even looked at the HTTP status code.
Patterns worth knowing ¶
The User-Agent block
A site behind a WAF returns 200 to a real browser but 403 to curl and to default clients. Our browser-UA probe passes; the curl-HEAD probe fails. The site isn't down, it's refusing non-browser traffic. Without multi-method data, a script or monitor hitting it with a plain client would report a false outage.
The protocol-only origin
Some origins only speak HTTP/1.1; some load balancers only negotiate HTTP/2. When the h1-strict and h2-relaxed cards disagree, you're looking at a protocol-support gap, not a down server.
The certificate problem
An expired, self-signed, or hostname-mismatched certificate fails strict TLS validation while the relaxed-TLS probe still completes the connection. When the strict probe fails and the relaxed one passes, the origin is up, its certificate is the problem, which is exactly the kind of failure a single browser check surfaces as an opaque "can't connect."
How isitdown.io does it ¶
Every check kicks off four parallel HTTP(S) probes:
- Methods: HTTP/1.1 strict TLS, HTTP/2 relaxed TLS, a browser-User-Agent GET, and a curl-User-Agent HEAD.
- Redirects: GET probes follow redirects once and read response headers.
- Timeout: 10 seconds per method (worst-case total wait is 10s, not 40s, they run in parallel).
- Phase timings: DNS lookup, TCP connect, TLS handshake, first byte, captured from the socket lifecycle where the client exposes them.
- Cadence: background monitors re-probe popular targets every 5 minutes.
Each per-method result includes the HTTP status code, the response time, and (when available) the phase timings, so you can tell slow DNS from slow TLS from slow first byte. See the fleet snapshot at isitdown.io/status.
Direct probes vs crowd-sourced reports ¶
Multi-method direct probes and crowd-sourced reports measure different things:
| Direct probes | Crowd reports | |
|---|---|---|
| What they measure | Network reachability right now | User-observed symptoms |
| Latency | Sub-second | Minutes |
| False positives | Rare | Common (trending topics, unrelated issues) |
| Coverage | Whatever a client can observe from our edge | Broad but biased toward popular services |
| Useful for | Confirming an outage, diagnosing why a request fails | Gauging user-visible impact |
Both have their place. If you're trying to figure out "is the site actually down, and for whom," direct multi-method probes answer faster and more reliably. If you're gauging user sentiment or UX-level issues that don't show up in HTTP responses, crowd data helps.
Try it ¶
Check any site's live 4-method status: isitdown.io · measure its speed with a published grade: isitdown.io/speed
See the fleet snapshot: isitdown.io/status
Related: Is it down for everyone or just me? · What 503 Service Unavailable means