Ping is often the first tool used to “check the network”. A few milliseconds of latency and zero packet loss are commonly interpreted as proof that everything is working well.
Unfortunately, ping answers a much narrower question than most people think.
Ping sends ICMP Echo Request packets and measures how long it takes to receive the corresponding Echo Replies.
This measures the round-trip time of a very specific type of traffic, handled by a very specific code path in the network stack and in intermediate devices.
ICMP packets are frequently treated differently from TCP or UDP traffic. They may be deprioritized, rate-limited, or even handled by the control plane instead of the fast forwarding path.
As a result, ICMP latency can be higher or lower than the latency experienced by actual application traffic.
Most real-world latency spikes are caused by queueing, not by propagation delay. Ping packets are small and infrequent, so they often bypass congestion effects that impact bulk data transfers.
A network can respond to ping with stable low latency while still delivering poor throughput or high jitter for real workloads.
Ping measures loss of ICMP packets in both directions combined. It does not tell you where the loss occurs, or whether only one direction is affected.
Many applications are sensitive to loss in one direction only, which ping cannot isolate.
Ping is excellent for detecting basic reachability and gross failures. If packets do not come back at all, something is clearly broken.
Beyond that, ping is best treated as a liveness probe — not a quality metric.