DiagnosticsEdge resolution

Ping Test

Measure round-trip latency and packet loss to any host from our server.

Quick presets

Edge Latency Probe

Enter an IP or domain above to measure network round-trip time, jitter, and packet loss from edge nodes.

Technical specification & engineering details

What this tool does

Measures real round-trip latency to a host by timing TCP connection setup from our server — the accurate, browser-accessible equivalent of ICMP ping, since neither browsers nor most hosted web servers can send raw ICMP echo packets.

Why TCP instead of ICMP?

Sending a traditional ICMP ping requires raw socket access, which is intentionally restricted on shared and cloud hosting for security reasons. Timing a TCP handshake instead gives you the same real network round-trip measurement — the three-way handshake still has to physically travel to the target and back — without needing elevated privileges.

Reading the results

Min/avg/max show the spread of round-trip times across four attempts; a wide spread often points to congestion or an unstable path rather than a consistently slow one. Packet loss here means a connection attempt timed out completely with no response at all, distinct from a fast "connection refused," which still confirms the host is reachable.

Troubleshooting high latency or packet loss

A ping time under about 20ms is excellent (typical for a well-routed connection to a nearby server), 20-100ms is normal for most regional and cross-country connections, and anything consistently above 150-200ms will start to feel laggy for real-time use like gaming or video calls. What matters more than the raw number is consistency -- a stable 80ms is usually fine, while a result that swings between 20ms and 300ms points to congestion somewhere on the path, often at a shared Wi-Fi access point, an oversaturated ISP link during peak hours, or an overloaded router hop.

Packet loss almost never originates at the destination server -- it is far more commonly a local Wi-Fi interference issue, a failing cable or port, or your ISP dropping packets under load. If you see loss on this tool but pages still load normally in your browser, that is expected: browsers retry failed TCP connections automatically, while a ping-style test reports every individual attempt.

Frequently asked questions

Is this the same as a real ICMP ping?

Not exactly — it measures TCP connection time rather than ICMP echo, since raw ICMP isn't available on standard web hosting. The round-trip time measured is still real and accurate.

What's a good ping time?

Under 20ms is excellent, 20-100ms is normal for most regional connections, and consistently above 150-200ms will feel laggy for gaming or video calls. Consistency matters more than the raw number.

What causes packet loss?

Most often local Wi-Fi interference, a failing cable or port, or ISP congestion -- rarely the destination server itself. If pages still load fine despite reported loss, that's expected: browsers retry failed connections automatically.

What's the difference between this and traceroute?

Ping tells you the round-trip time to the final destination; traceroute shows you every hop along the way, which is more useful for finding exactly where in the path a slowdown or drop is happening.

Can I test ping to a specific port?

Yes -- enter host:port (e.g. example.com:443) to time the TCP handshake against a specific service instead of the default port this tool checks.