"The site is slow." Three words that launch a thousand support tickets — and the first question is always the same: is it us, the network in between, or them?
Three classic tools answer exactly that, and they've been around for decades because they work: ping, traceroute, and the one that combines them, MTR. Knowing how to read them turns "it's slow, I dunno why" into "hop 6, the transit provider, is dropping packets." Let's learn them.
Ping: is it alive, and how far?
Ping is the simplest network tool. It sends a small packet to a host and times how long the reply takes. It answers two questions:
- Reachability — does the host respond at all?
- Round-trip time (RTT) — how many milliseconds there and back?
ping example.com
64 bytes from 192.0.2.10: time=24.3 ms
What to read:
| You see | It means |
|---|---|
| Fast, steady replies | Healthy connection |
| High RTT | Latency — far away or congested |
| Some replies missing | Packet loss — unstable link |
| No replies at all | Unreachable, or blocking ping |
Ping tells you that there's a problem and roughly how bad — but not where it is. For that, you trace the route.
Traceroute: where does it go (and break)?
Traceroute maps the path your packets take to reach a host — every router ("hop") along the way, with the latency to each:
1 router.local 1 ms
2 isp-gateway 8 ms
3 transit-provider 22 ms
4 ... 45 ms
5 ... 210 ms ← jumps here
6 example.com 60 ms
The skill is reading the pattern, not the individual numbers:
- Latency that rises and stays high from a certain hop onward → the problem likely started there.
- A single high hop that goes back down → often harmless (some routers de-prioritise replying to traceroute, but still forward traffic fine).
- The trace stops at a hop → packets may be dying there (or that hop just doesn't reply).
Don't panic at one slow hop. Routers often answer traceroute slowly while forwarding real traffic perfectly. What matters is high latency or loss that persists across the following hops.
MTR: the best of both, live
MTR ("My TraceRoute") combines ping and traceroute and runs them continuously. Instead of a single snapshot, it shows every hop with live, rolling stats — latency and packet loss per hop, updating in real time.
That's a big deal, because the most revealing network problems are intermittent. A one-off traceroute might look fine; MTR running for a minute reveals the hop that drops 20% of packets only sometimes. It's the tool the pros reach for when a problem won't sit still.
Which tool, when?
| Question | Tool |
|---|---|
| Is the host up? How's the latency? | Ping |
| Where along the path is it slow or broken? | Traceroute |
| Is there intermittent loss/latency, and where? | MTR |
A typical flow: ping to confirm there's a problem → traceroute to locate it → MTR to watch a flaky hop over time.
From one-off command to always-on
These tools are perfect for diagnosing a problem you already know about. But you don't want to be running them by hand to discover one. That's where monitoring comes in: continuous ping checks catch reachability and packet-loss problems automatically, and a continuous network-path (MTR-style) monitor watches the whole route so you see a bad hop the moment it appears — not when a customer complains.
The bottom line
| Tool | Answers | Reach for it when… |
|---|---|---|
| Ping | Up? How fast? | You need a quick health/latency check |
| Traceroute | Where's the problem? | You need to locate it along the path |
| MTR | Where, and how often? | The problem is intermittent |
Master these three and "the network is weird" becomes a question you can actually answer. They turn a vague slowdown into a specific hop with a specific problem — which is the whole battle.
Try them without installing anything: the free ping and traceroute tools. For always-on coverage, see network monitoring.