How to check network latency in Linux

Slow shells, delayed API calls, and uneven remote desktop sessions need a latency check before application logs can be trusted. Measuring round-trip time and packet loss from the affected Linux host separates local access delay from a remote service or route problem.

The quickest baseline is a short ping to the default gateway followed by the same test against the affected endpoint or a known public target. The gateway result shows whether the local hop is adding delay, while the remote result shows the wider path seen by that host at that moment.

Use tracepath after ping when the remote sample has spikes, loss, or a much higher average than the local baseline. tracepath prints responding hops, missing diagnostic replies, and path MTU notes, but intermediate no-reply hops are common because routers may limit diagnostic traffic even when forwarding works.

1. Choose the target that represents the slow service.

   Use the service hostname when DNS or load-balancer routing is part of the complaint. Use a stable public IP such as 1.1.1.1 only when the goal is to compare the internet path itself.

2. Show the default gateway for a local baseline.

   $ ip route show default
   default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.40 metric 100

3. Measure latency to the default gateway.

   $ ping -c 4 192.168.1.1
   PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
   64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.509 ms
   64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.023 ms
   64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.079 ms
   64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.097 ms
   
   --- 192.168.1.1 ping statistics ---
   4 packets transmitted, 4 received, 0% packet loss, time 3105ms
   rtt min/avg/max/mdev = 0.023/0.177/0.509/0.193 ms

   Low gateway latency with no packet loss points away from the local wired or wireless hop.

4. Measure latency to the affected endpoint or comparison target.

   $ ping -c 4 1.1.1.1
   PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
   64 bytes from 1.1.1.1: icmp_seq=1 ttl=63 time=8.84 ms
   64 bytes from 1.1.1.1: icmp_seq=2 ttl=63 time=6.78 ms
   64 bytes from 1.1.1.1: icmp_seq=3 ttl=63 time=6.99 ms
   64 bytes from 1.1.1.1: icmp_seq=4 ttl=63 time=13.4 ms
   
   --- 1.1.1.1 ping statistics ---
   4 packets transmitted, 4 received, 0% packet loss, time 3014ms
   rtt min/avg/max/mdev = 6.782/8.999/13.377/2.651 ms

   avg is the typical round-trip time in this short sample, while max and mdev show spikes and variation. Treat packet loss as a stronger warning than a small average change.

5. Trace the first hops to the same endpoint.

   $ tracepath -n -m 8 1.1.1.1
    1:  192.168.1.1                                          0.128ms
    2:  100.64.0.1                                           1.095ms pmtu 1500
    3:  no reply
    4:  198.51.100.9                                         5.582ms
    5:  203.0.113.22                                        15.576ms asymm  6
    6:  no reply
    7:  198.51.100.45                                        8.047ms asymm  6
    8:  no reply
        Too many hops: pmtu 1500
        Resume: pmtu 1500

   Look for latency that rises and stays high on later responding hops. A single middle no reply row usually means that router did not answer the probe, not that forwarding stopped.

6. Collect a longer summary sample when the symptom is intermittent.

   $ ping -c 10 -q 1.1.1.1
   PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
   
   --- 1.1.1.1 ping statistics ---
   10 packets transmitted, 10 received, 0% packet loss, time 9037ms
   rtt min/avg/max/mdev = 5.705/6.571/7.449/0.558 ms

   -q keeps only the summary lines. Increase the count during the complaint window when spikes or packet loss happen only occasionally.