Send a website three HTTP requests in a row and review the response times, reachability, and packet-loss figure — an application-layer check rather than a network ICMP ping.
Pro tip: An average above 1500ms flags slow origin latency worth investigating on hosting or caching.
The classic ping command sends ICMP echo packets at the network layer. This tool works one layer up: it sends three real HTTP GET requests to the URL you provide and times the responses our Cloudflare edge gets back. The distinction matters because plenty of hosts silently drop ICMP yet answer HTTP perfectly well, and HTTP is what your visitors and search crawlers actually use. The label on the result says so plainly: it is HTTP-level timing from a single edge location, not an ICMP ping.
Sending three requests rather than one smooths out a single unlucky round trip and gives a fairer picture of how the endpoint is behaving from moment to moment.
Tightly clustered timings with 0% loss suggest a steady, healthy endpoint. A wide gap between the fastest and slowest attempt suggests jitter, an origin under load, or a flaky route even if every request technically succeeds. Any packet loss at all on a simple three-sample probe is worth a second run, because a single missed request can be noise, but a repeatable 33% or higher points at a real reachability problem.
These timings cover the HTTP response for the URL only; they do not include downloading images, scripts, or stylesheets, so they are not a full page-speed score. The packet-loss figure is loss of HTTP responses across three samples, not network-layer packet loss in the ICMP sense, and three samples is a small set, so treat a single result as indicative rather than definitive. Readings are taken from our edge to the host over one route, so they will not match a stopwatch in a browser on a distant connection. As with any automated request, the probe uses an identified tool user agent, so a site that filters non-browser traffic may answer slowly or refuse some attempts and inflate the loss figure. Only publicly reachable hosts are probed.
Input: https://example.com
Output: Reachable: Yes • Avg response: 143 ms • Packet loss: 0% • Request 1: 142 ms (HTTP 200), Request 2: 138 ms (HTTP 200), Request 3: 150 ms (HTTP 200)
Tight clustering with zero loss indicates a stable, responsive host.
Input: https://example.net
Output: Reachable: Yes • Avg response: 345 ms • Packet loss: 33% • Request 1: 210 ms (HTTP 200), Request 2: no response, Request 3: 480 ms (HTTP 200)
One missed request and a wide spread; re-run to see whether the loss repeats.
No. The terminal ping uses ICMP at the network layer; this tool sends real HTTP requests, which is a more relevant test for a website that may ignore ICMP entirely.
Three per run. A single request can be unluckily fast or slow, so three reveal whether the timing is consistent and whether reachability holds up, while keeping the check quick.
It is the share of the three HTTP requests that got no response: 0% if all answered, 33% if one missed, 100% if none did. It is response loss at the HTTP layer, not ICMP packet loss.
No. They measure the response for the URL itself, not the download of every embedded image, script, or stylesheet, so they are not a complete load-time figure.
Brief jitter, origin load, or a request being filtered can cause a single miss. A pattern of misses across repeated runs is far more telling than one isolated failure.
Not exactly. It is measured from one Cloudflare edge location over a single route, so use it for relative comparison rather than as the latency a visitor on a distant connection experiences.
Our editorial and data-source notes explain how each check works and where estimates come from.