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: 12 ms • Packet loss: 0% • Fastest: 7 ms, Slowest: 21 ms • Request 1: 21 ms (HTTP 200), Request 2: 7 ms (HTTP 200), Request 3: 7 ms (HTTP 200)
Measured 2026-07-17 from our edge. Zero loss and single-digit warm responses. Absolute timings depend on the route between our edge and the host and will differ from your own run.
Input: https://en.wikipedia.org/wiki/Search_engine_optimization
Output: Reachable: Yes • Avg response: 18 ms • Packet loss: 0% • Fastest: 11 ms, Slowest: 31 ms • Request 1: 31 ms (HTTP 200), Request 2: 11 ms (HTTP 200), Request 3: 11 ms (HTTP 200)
Measured 2026-07-17. Request 1 pays for connection setup and the next two come back warm — a routine pattern, and the reason three samples tell you more than one. Timings shift between runs.
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.
I document how each check works, where its data comes from, and which parts are only estimates.