When a website is slow, a game lags or a video call keeps freezing, two simple commands can tell you a lot about what is going on: ping and traceroute. They are built into every operating system and available online in our ping test and traceroute tool. This guide explains what the numbers mean and how to use them to find the source of a problem.
Part 1: Ping
How ping works
Ping sends a small ICMP “echo request” packet to a host and waits for an “echo reply”. It measures the round-trip time (RTT) – how long the packet takes to get there and back – in milliseconds. Repeat it several times and you also learn about consistency and loss.
Run it yourself:
Windows: ping example.com
macOS / Linux: ping -c 10 example.comReading the output
64 bytes from 93.184.215.14: icmp_seq=1 ttl=56 time=24.1 ms
64 bytes from 93.184.215.14: icmp_seq=2 ttl=56 time=23.8 ms
64 bytes from 93.184.215.14: icmp_seq=3 ttl=56 time=61.5 ms
Request timeout for icmp_seq 4
64 bytes from 93.184.215.14: icmp_seq=5 ttl=56 time=24.3 ms
--- example.com ping statistics ---
5 packets transmitted, 4 received, 20% packet loss
round-trip min/avg/max/stddev = 23.8/33.4/61.5/16.2 ms- time – the round-trip time for each packet. Lower is better.
- ttl – “time to live”, a counter decremented by every router. It hints at how many hops away the host is, but different systems start from different values (often 64, 128 or 255).
- Request timeout – no reply arrived in time; counted as packet loss.
- min/avg/max – the spread of response times.
- stddev (or the difference between packets) – a measure of jitter, the variation in delay.
The three numbers that matter
| Metric | Good | Noticeable | Problem |
|---|---|---|---|
| Latency (avg) | < 50 ms | 50–150 ms | > 150 ms (unless very far away) |
| Jitter | < 5 ms | 5–30 ms | > 30 ms |
| Packet loss | 0% | < 1% | > 1–2% |
Distance sets a floor on latency: light in fibre covers roughly 200 km per millisecond, so a round trip of 10,000 km can never take less than about 50 ms. A steady 180 ms to a server on another continent is normal; 180 ms to a server in your own city is not.
When ping shows 100% loss
Many servers and firewalls block ICMP on purpose. If a website opens in your browser but ignores pings, nothing is wrong. Only treat total loss as “down” if the service itself also fails.
Part 2: Traceroute
How traceroute works
Traceroute sends packets with a TTL of 1, then 2, then 3, and so on. Each router along the path decrements the TTL; when it reaches zero, the router discards the packet and sends back a “time exceeded” message. By collecting those messages, traceroute lists every router (“hop”) between you and the destination, with the round-trip time to each.
Windows: tracert example.com
macOS / Linux: traceroute example.comEach line shows the hop number, the router’s name or IP, and usually three timing measurements.
Rule 1: Asterisks are usually harmless
A line of * * * means that router did not reply. Many routers are configured to ignore or rate-limit traceroute probes while still forwarding traffic normally. If later hops respond, the path is fine.
Rule 2: Only latency that persists matters
Routers handle traceroute replies on a slow, low-priority path. One hop showing 200 ms while the next hops show 30 ms is not a problem – that router is just slow to reply about itself. A real problem shows as an increase that continues for every hop after it, all the way to the destination.
Rule 3: Expect big jumps on long links
An increase of 70–80 ms between Europe and the US east coast, or 150+ ms between Europe and Asia, is just the length of the undersea cables. Router names with city or airport codes (lon, fra, ams, nyc, sin, hkg) help you see where those long links are.
Rule 4: Loss must also persist
Like latency, packet loss at one intermediate hop that disappears at later hops is just rate limiting. Loss that starts at a hop and continues to the destination points to a real problem at or just before that hop.
Putting it together: a diagnosis routine
- Test your local network. Ping your router (for example
ping 192.168.1.1). On wired Ethernet it should be under 1–2 ms; on Wi-Fi, under about 10 ms with no loss. High numbers here mean a Wi-Fi or local problem – move closer, change the Wi-Fi channel, or use a cable. - Test the wider internet. Ping a reliable public host such as
1.1.1.1or8.8.8.8. If this is bad but your router is fine, the issue is with your connection or provider. - Test the specific service. If general internet is fine but one site or game server is slow, run a traceroute to it to see where latency or loss begins.
- Test from outside. Use our online ping and traceroute, which run from our server. If the host is fine from our side but slow from yours, the problem is on your route; if it is slow from everywhere, the problem is at the destination.
- Repeat at different times. Problems only during the evening peak usually mean congestion in your provider’s network.
Reporting a problem
When you contact your provider or a game’s support team, include: the time and time zone, your public IP (from our home page), a ping to your router and to the destination, and a traceroute to the destination – ideally one taken while the problem is happening and one when it is not. Tools like MTR (macOS/Linux) or WinMTR (Windows), which combine ping and traceroute over many minutes, give the clearest picture.