Response Time Checker

What this actually measures

Each probe is a full HTTP response time — the time from the moment Cloudflare's edge initiates the request until the response headers come back. That includes DNS resolution (cached at the colo, so usually fast), TCP connection setup, TLS handshake (on first probe; subsequent probes can reuse the connection), and the server's processing time before it starts streaming the response. In web-performance jargon this is TTFB — Time To First Byte, the single most important latency metric for page-load perception.

Why HTTP instead of ICMP ping

Traditional ping uses ICMP echo packets at the network layer. They're light, they bypass the application stack, and they tell you the round-trip time between two hosts. They also tell you almost nothing about what a user will actually experience. A server can have a 5 ms ICMP RTT and a 500 ms TTFB if PHP is slow to render. They can also be filtered entirely — many cloud providers and enterprise firewalls block ICMP by default, while leaving HTTPS wide open. HTTP-layer probing reflects what your users actually see.

Workers also can't do ICMP — Cloudflare's runtime exposes fetch(), not raw sockets. So even if we wanted classic ping, we couldn't.

Understanding the results

• Under 50 ms — Excellent. The target is on the same continent and behind a CDN, or you happen to share a region with the origin.
• 50–150 ms — Good. Well-optimised origin in a different region, or one ocean away.
• 150–300 ms — Average. Trans-continental hop, no CDN.
• Over 300 ms — Slow. A distant origin without a CDN, an overloaded server, or a deep render path (a classic CMS without page caching can easily land here).

Jitter (max − min) tells you how stable the connection is. A 200 ms average with 5 ms jitter is a fast, stable link. A 200 ms average with 180 ms jitter is unstable — probably a congested transit link or an origin that's overloaded for a fraction of requests.

About the probe location

Every probe in a given lookup runs from the same Cloudflare edge — specifically whichever colo handled the inbound request that triggered this Worker. The card at the top of the results shows which one (a three-letter airport code mapped to a city). To measure from a different geography, run the request from a client in that region — many residential ISPs in different countries will get routed to different colos. For a proper synthetic-monitoring setup with simultaneous probes from dozens of locations, commercial tools like Catchpoint, Uptrends, or Pingdom are the right call.

This is a server-side check, not a client-side ping. It measures the path from Cloudflare's edge to the target, not the path from your browser. If your local connection is bad but Cloudflare's path to the target is fast, you'll still see a small number here.