What ping measures
An ICMP echo request (type 8) goes out; the host answers with an echo reply (type 0); ping records the elapsed time. That round-trip time is the sum of the propagation delay in the fibre, the queuing and forwarding delay at every router in between, and however long the target's kernel takes to answer. What it is not is a measure of application performance — a server can answer ICMP in 12 ms while its web application takes four seconds to render a page.
Four numbers come out of a run, and each answers a different question:
- min — the best case, closest to pure propagation delay. Over long distances it is bounded by physics: light in fibre travels roughly 200,000 km/s, so a 5,000 km path cannot round-trip faster than about 50 ms no matter what you buy.
- avg — the number to quote and to track over time.
- max — the worst probe. A max far above avg means something in the path buffers or deprioritises traffic in bursts.
- mdev / stddev (jitter) — how much the times vary. For real-time traffic (VoIP, gaming, video calls) jitter matters more than average latency; a stable 80 ms is more usable than a 40 ms average that swings between 10 and 300.
When 100% packet loss does not mean "down"
This is the single most misread result in networking. A great many hosts are configured to ignore ICMP echo requests entirely — cloud security groups routinely omit ICMP from their default rules, corporate firewalls drop it as policy, and some CDNs rate-limit it aggressively. A host can serve millions of HTTPS requests a second while answering no pings at all.
Read the full explanation of ping test results ↓Show less ↑
The reverse mistake is just as common: a host that answers ping is not necessarily healthy. ICMP is handled by the kernel and keeps working long after the application layer has fallen over. "It pings, so it is up" has misled a lot of on-call engineers.
Reading partial loss
Loss between 1% and 99% is more interesting than either extreme, and its meaning depends on where it appears:
| Pattern | Likely cause | Next step |
|---|---|---|
| Steady low loss (1–5%) with normal latency | ICMP rate limiting on the target or an intermediate router. | Usually harmless. Confirm with TCP — real traffic is often unaffected. |
| Loss that rises with latency | Congestion: a queue is filling and then dropping. | Traceroute to find where the latency jumps. |
| Loss only at intermediate hops, none at the destination | Routers deprioritising ICMP directed at themselves. | Ignore it. Only end-to-end loss counts. |
| Bursty loss with high jitter | A saturated link, a flapping wireless segment, or a duplex mismatch. | Check interface error counters at both ends. |
| 100% loss but TCP works | ICMP is filtered. | Nothing to fix — use TCP checks for this host from now on. |
Latency you should expect
Rough figures for a wired connection, useful as a sanity check rather than a target: same city, 1–10 ms; same country, 10–40 ms; cross-continent, 60–120 ms; intercontinental, 120–300 ms. Satellite is a category of its own — geostationary links start around 550 ms because of the altitude, while low-earth-orbit services land in the 25–60 ms range. Mobile networks add 20–60 ms over the equivalent fixed path.
Because this tool pings from our server, the absolute numbers describe our path to the host, not yours. Use them comparatively: ping the host in question and a known-good reference such as 1.1.1.1 from the same place, and compare. A big gap between the two is a signal; the raw value on its own is not.
The command-line equivalent
Ping is on every operating system, and the flags differ enough to be worth writing down:
# Linux: -c count, -w overall deadline in seconds
ping -c 4 -w 10 example.com
# macOS/BSD: -t is the overall timeout; IPv6 uses a separate binary
ping -c 4 -t 10 example.com
ping6 -c 4 2606:4700:4700::1111
# Windows: -n count
ping -n 4 example.com
# A long run to catch intermittent loss, with a timestamp on every line:
ping -c 600 -i 1 example.com | ts
# Continuous latency + loss per hop, the best single tool for this job:
mtr -rw -c 100 example.commtr is worth installing. It combines ping and traceroute, running continuously and showing loss and latency for every hop at once, which is how you find the specific link responsible for intermittent trouble. A four-packet ping cannot see a problem that happens twice an hour; a 600-packet run can.
Where ping fits in a diagnosis
Ping answers "is there a path, and how long is it?" — nothing more. Start with DNS to confirm the name resolves to the address you expect, ping to test the path, traceroute to find where a bad path goes wrong, and the port checker to confirm the service itself is accepting connections. Skipping straight to ping and stopping there is how "the server is down" tickets get filed against servers that are fine.