How to check network latency in Linux

Network latency determines how quickly packets travel between hosts, affecting interactive shells, API calls, and database queries on Linux systems. Early latency measurements separate slow links from slow applications during troubleshooting.

The ping utility measures round-trip time (RTT) using ICMP Echo requests, producing delay and loss statistics that are easy to compare over time. The tracepath utility probes the route using increasing TTL values to show where latency grows hop by hop, plus path MTU (PMTU) details when available.

Firewalls or routers may block or rate-limit ICMP, producing timeouts or misleading spikes even when application traffic is healthy. Multiple targets plus a nearby baseline (default gateway) provide context, while longer samples reveal jitter and intermittent packet loss.

1. Select a test target on the same path as the affected service, such as the default gateway or the service endpoint.

   203.0.113.50 in the examples is a placeholder public IP; substitute the actual target for real tests.

2. Display the default gateway address for a local baseline.

   $ ip route show default
   default via 192.0.2.1 dev eth0 

3. Measure LAN latency to the default gateway using ping.

   $ ping -c 4 192.0.2.1
   PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
   64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.062 ms
   64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.088 ms
   64 bytes from 192.0.2.1: icmp_seq=3 ttl=64 time=0.096 ms
   64 bytes from 192.0.2.1: icmp_seq=4 ttl=64 time=0.090 ms
   
   --- 192.0.2.1 ping statistics ---
   4 packets transmitted, 4 received, 0% packet loss, time 3063ms
   rtt min/avg/max/mdev = 0.062/0.084/0.096/0.013 ms

   Sub-millisecond avg latency with very low mdev is typical on a healthy wired LAN.

4. Measure round-trip times with ping.

   $ ping -c 4 203.0.113.50
   PING 203.0.113.50 (203.0.113.50) 56(84) bytes of data.
   64 bytes from 203.0.113.50: icmp_seq=1 ttl=63 time=6.97 ms
   64 bytes from 203.0.113.50: icmp_seq=2 ttl=63 time=7.02 ms
   64 bytes from 203.0.113.50: icmp_seq=3 ttl=63 time=10.4 ms
   64 bytes from 203.0.113.50: icmp_seq=4 ttl=63 time=9.53 ms
   
   --- 203.0.113.50 ping statistics ---
   4 packets transmitted, 4 received, 0% packet loss, time 3014ms
   rtt min/avg/max/mdev = 6.969/8.477/10.392/1.514 ms

   avg represents typical latency, while mdev represents variability (jitter).

   100% packet loss can indicate ICMP filtering or rate limiting, not a dead host.

5. Trace the network path to the same endpoint.

   $ tracepath -n -m 8 203.0.113.50
    1:  192.0.2.1                                            0.065ms 
    2:  192.0.2.1                                            0.023ms pmtu 1500
    2:  203.0.113.1                                          0.275ms 
    3:  no reply
    4:  203.0.113.2                                         7.051ms 
    5:  203.0.113.3                                          9.484ms asymm  7 
    6:  203.0.113.4                                           7.045ms asymm  5 
    7:  203.0.113.5                                           6.816ms asymm  5 
    8:  203.0.113.50                                       20.037ms asymm  6 
        Too many hops: pmtu 1500
        Resume: pmtu 1500 

   The first hop where timing increases significantly is commonly where latency is introduced; intermediate hops may omit replies due to filtering.

6. Collect a longer latency sample with quiet output to estimate jitter and intermittent loss.

   $ ping -c 10 -i 0.2 -q 203.0.113.50
   PING 203.0.113.50 (203.0.113.50) 56(84) bytes of data.
   
   --- 203.0.113.50 ping statistics ---
   10 packets transmitted, 10 received, 0% packet loss, time 1866ms
   rtt min/avg/max/mdev = 6.389/34.714/248.729/72.013 ms, pipe 2

   Increasing the count improves confidence on noisy links, while rising mdev indicates unstable latency.