How it works

Each check sends a small HTTPS request from your browser to our test server and measures how long a valid response takes. The timer uses performance.now(), which is accurate to fractions of a millisecond.

The number you see includes several things stacked together: network travel to the server, the server processing the request, connection setup when a new connection is needed, and your browser's own scheduling. It is not pure ICMP ping.

We validate every response three ways: the HTTP status must be successful, the body must be valid JSON, and a unique random nonce we sent must be echoed back exactly. This stops a cached page, a captive portal, an HTML fallback, or an opaque response from being counted as a successful check.

A test moves through a clear state machine: idle → warming-up → running → paused/stopping → completed.

• Warm-up: a short, separately marked period at the start so the first request isn't penalized by cold connection setup. Warm-up samples are excluded from your final statistics.
• Running: roughly one request per second, with a five-second timeout each. Requests never overlap the same target.
• Paused: if this tab is hidden or your device reports no network, measurement pauses. The gap is recorded but never counted as a failure or an outage.
• Completed: the full duration finished, or you stopped early for a clearly labeled partial result.

All percentages use attempted checks as the denominator — intervals where no request was attempted (because the tab was hidden) are never counted as failures.

• Median response time: the middle value of all successful response times.
• 95th percentile: the value that 95% of successful responses were faster than.
• Response-time variation: the mean absolute difference between consecutive valid response times within contiguous observed sequences. Gaps break the sequence so we don't compare across an outage. This is a product heuristic — it is not standardized network jitter.
• Longest reachability gap: the longest span during the test with no successful check. We label this an observed test-server reachability gap, not proof of a whole-internet outage.

This tool does not and cannot measure: Wi-Fi signal strength, router health, nearby connected devices, whether you're on 2.4 GHz or 5 GHz, exact ISP faults, download or upload speed in Mbps, or true packet loss. A failed HTTP request is not measured packet loss — it means the check did not reach the test server successfully.

A single endpoint failing does not prove your entire internet is down. If you want to check that, try another website.