Skip to content

HTTP Ping

Browser-side · queries to public APIs
Last verified June 2026 — runs in your browser

HTTP Ping — Latency & Jitter Test from Cloudflare's Edge

HTTP ping measures round-trip response time by sending a series of HTTP(S) requests from Cloudflare's global edge network to the target host and recording the elapsed time for each. This is not an ICMP echo (ping per RFC 792, Postel 1981) — it operates at the application layer (HTTP/1.1 per RFC 9112, HTTP/2 per RFC 9113) rather than the network layer, and it includes TLS handshake time (RFC 8446 TLS 1.3, Rescorla 2018) plus the server's own processing time in every sample. The measurement runs from Cloudflare's anycast network (RFC 4786 BCP 126, Abley & Lindqvist 2006), meaning the probe originates close to the target from an infrastructure perspective, not from your device or your ISP. Minimum latency reflects the best-case edge-to-server path under favourable conditions. Average and maximum show the typical range and worst case. Jitter — the variance between consecutive samples — indicates stability: low jitter means consistent performance; high jitter suggests queue fluctuations, CDN origin routing variability, or server-side processing inconsistency. A fast rating corresponds to average response times under 300 ms; moderate to under 1 s; slow beyond that. These thresholds align with HTTP response time guidelines from RFC 9110 §15 context and general web performance research. Reachability reports the fraction of samples that received a valid HTTP response — 100 % means all probes succeeded, lower values indicate intermittent timeouts or connection failures.

Related:

Website Status Check website uptime, response time, and server status Is It Down? Check if a website is down for everyone or just you Site Speed Check Core Web Vitals (LCP, INP, CLS, FCP, TTFB) from real Chrome user data DNS Lookup Query DNS records for any domain — A, AAAA, MX, CNAME, TXT, NS, SOA HTTP Ping Measure HTTP(S) response time from Cloudflare's global edge — latency, jitter, and reachability across 5 samples What Is My IP See your public IP address, location, ISP, and network details

How to use the HTTP ping tool

  1. Enter a hostname or full URL (e.g. github.com or https://api.example.com/health).
  2. Click Ping — the tool sends 5 HTTP(S) requests from Cloudflare's edge and records response time for each.
  3. Read min/avg/max/jitter: min is the best-case path latency; avg the typical; max the worst; jitter the variance between samples.
  4. Check Reachability — if below 100 %, some probes timed out or failed, indicating intermittent connectivity issues at the edge-to-origin path.

Common use cases

  • Comparing HTTP response times of two API endpoints or CDN origins to choose the faster one.
  • Spotting high jitter that causes inconsistent API response times even when the average looks fine.
  • Verifying that a newly deployed server is reachable from Cloudflare's edge before wiring it into production.
  • Checking whether a third-party dependency (payment gateway, auth provider) is responding within budget.

Frequently asked questions

Is this a real (ICMP) ping?

No. ICMP ping (RFC 792) operates at the IP layer and measures pure network round-trip time with no TLS or application overhead. This tool sends HTTP(S) requests from Cloudflare's global edge and measures application-layer response time — it includes TCP connection setup, TLS handshake (RFC 8446 TLS 1.3), and the server's own processing time. For a true ICMP ping from your device, use your OS command: ping github.com in a terminal.

Why is the first sample often slower?

The first sample establishes a fresh TCP connection and completes a full TLS handshake (RFC 8446), which adds one to two round-trips of overhead. Subsequent samples may reuse an existing connection depending on the server's keep-alive settings, reducing that overhead. The minimum across all samples is typically the best approximation of the steady-state latency.

Does this measure latency from my device?

No. The probe runs from Cloudflare's anycast edge network (RFC 4786 BCP 126), not from your browser or ISP. The numbers reflect the latency between Cloudflare's infrastructure and the target — useful for understanding infrastructure-level performance, but it does not include your own last-mile connection time.

What does high jitter indicate?

Jitter is the variance between consecutive samples. Low jitter means the server responds consistently. High jitter suggests queue fluctuations, origin routing variability behind a CDN, garbage-collection pauses, or overloaded server resources. Even a good average response time can mask high jitter, which is what makes APIs feel unreliable.

HTTP ping vs ICMP ping — what the latency numbers actually mean

ICMP ping (RFC 792, Postel 1981) sends echo request/reply datagrams at the IP layer and measures pure network round-trip time without involving any application, TCP, or TLS overhead. The OS ping command is the canonical tool for this. HTTP ping operates at the application layer: it opens a TCP connection, performs a TLS handshake (on HTTPS), sends an HTTP GET or HEAD request per RFC 9110 (Fielding, Nottingham & Reschke 2022), and records the time until the first response byte or connection close. This means HTTP latency includes TCP SYN-ACK round-trip (typically close to ICMP RTT), TLS handshake (one or two additional round-trips under TLS 1.2; one under TLS 1.3 with 0-RTT, Rescorla 2018 RFC 8446), and server processing (database queries, application logic, content generation). For the first sample, TLS session resumption is not possible, so the handshake cost is always present — subsequent samples may benefit from keep-alive reuse depending on server configuration. In practice, the minimum across five samples approximates the edge-to-server network latency plus a single TLS 1.3 handshake. Jitter matters for API reliability and real-time workloads: a server that responds in 80 ms half the time and 800 ms the other half has high jitter even if the average looks acceptable. Compare multiple targets to diagnose whether high latency is origin-side (same host, multiple paths) or network-path-side (different hosts, same pattern). Because the probe originates from Cloudflare's network — not from your device — the numbers reflect infrastructure-level latency between Cloudflare's edge and the target, which is relevant for serverless, CDN, and API latency budgets but does not include your own last-mile connection.

  • 5 HTTP(S) samples — min, avg, max, and jitter reported
  • Reachability percentage across all samples
  • Latency rated: Fast (<300 ms avg) / Moderate (<1 s) / Slow
  • Honest ICMP vs HTTP distinction — TLS + server processing included
  • Probe originates from Cloudflare's anycast edge (RFC 4786 BCP 126)

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (3)
  • Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (June 2022 — STD 97; §15 status code classes; the tool measures HTTP(S) round-trip time from Cloudflare's edge to the target, including TLS handshake and server processing time — this is NOT an ICMP ping and does NOT measure latency from the user's device).
  • Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF (August 2018 — TLS 1.3 handshake latency is included in the measured response time; 1-RTT full handshake + optional 0-RTT on resumption).
  • Postel, J. (1981). Internet Control Message Protocol (ICMP). RFC 792, IETF (September 1981 — defines ICMP Echo Request/Reply; this tool does NOT use ICMP: it issues an HTTP(S) request, which traverses TCP+TLS+application layers rather than raw network-layer RTT).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

By ·