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 proto dhcp src 192.0.2.40 metric 100 

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=128 time=0.285 ms
   64 bytes from 192.0.2.1: icmp_seq=2 ttl=128 time=2.73 ms
   64 bytes from 192.0.2.1: icmp_seq=3 ttl=128 time=0.764 ms
   64 bytes from 192.0.2.1: icmp_seq=4 ttl=128 time=0.518 ms
   
   --- 192.0.2.1 ping statistics ---
   4 packets transmitted, 4 received, 0% packet loss, time 3054ms
   rtt min/avg/max/mdev = 0.285/1.075/2.733/0.972 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=128 time=5.21 ms
   64 bytes from 203.0.113.50: icmp_seq=2 ttl=128 time=8.58 ms
   64 bytes from 203.0.113.50: icmp_seq=3 ttl=128 time=5.54 ms
   64 bytes from 203.0.113.50: icmp_seq=4 ttl=128 time=6.79 ms
   
   --- 203.0.113.50 ping statistics ---
   4 packets transmitted, 4 received, 0% packet loss, time 3015ms
   rtt min/avg/max/mdev = 5.207/6.530/8.580/1.322 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?: [LOCALHOST]                      pmtu 1500
    1:  no reply
    2:  no reply
    3:  no reply
    4:  no reply
    5:  no reply
    6:  no reply
    7:  no reply
    8:  no reply
        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 1838ms
   rtt min/avg/max/mdev = 4.711/8.770/19.959/4.482 ms

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