Ping tells you that a server is slow or dropping packets. It doesn't tell you where the problem is. Between you and any server sit a dozen or more routers — your gateway, your ISP, transit providers, the destination's network — and the trouble could be at any one of them. Traceroute is the tool that turns "the connection is bad" into "the third hop, inside my ISP, is adding 200ms and dropping packets." It maps the path and shows you exactly where things go wrong.
This guide explains how traceroute works, how to read its output without being misled, and how to combine it with ping and MTR to diagnose real network problems.
What Traceroute Does
Traceroute reveals the sequence of routers (hops) a packet passes through to reach a destination, and how long each hop takes. Run traceroute example.com (macOS/Linux) or tracert example.com (Windows) and you get a numbered list: hop 1 is usually your local gateway, the last is the destination, and everything between is the path across the internet.
For each hop you typically see its IP/hostname and three round-trip times. That's enough to answer the questions ping can't:
- Where does latency suddenly jump?
- At which hop do packets start getting dropped?
- Whose network is the problem on — yours, your ISP's, or the destination's?
How Traceroute Works (the TTL Trick)
Traceroute's mechanism is a clever hack on a field every IP packet already carries: TTL (Time To Live). TTL is a counter that every router decrements by one as it forwards a packet. When TTL hits zero, the router discards the packet and sends back an ICMP "Time Exceeded" message — a safety feature to stop packets looping forever.
Traceroute weaponizes this to map the path:
- Send a packet with TTL = 1. The first router decrements it to 0, drops it, and replies "Time Exceeded" — revealing hop 1.
- Send a packet with TTL = 2. It dies at the second router, revealing hop 2.
- Keep incrementing TTL until the packet finally reaches the destination, which replies differently (signaling the end).
Each "Time Exceeded" reply identifies one router along the way, and the round-trip time of each reply gives that hop's latency. (Different tools send UDP, ICMP, or TCP probes — TCP traceroute to port 443 is often best, since firewalls that block ICMP usually allow web traffic.)
How to Read Traceroute Output
Reading traceroute well means knowing what's a real problem and what's a harmless artifact. The traps catch even experienced engineers:
- A single slow or
* * *hop in the middle is usually NOT the problem. Routers treat "packets addressed to me" (the Time Exceeded reply) as low priority and may delay or ignore them, even while forwarding real traffic perfectly. Only believe a problem if it persists to the destination. A 250ms spike at hop 5 that drops back to 30ms at hop 6 is an artifact, not a fault. - Look at the trend across hops, not one number. Latency should generally rise gradually with distance. A jump that stays high for every subsequent hop marks where the real latency was introduced.
* * *(timeouts) often just mean a router is configured not to reply to traceroute. If later hops respond fine, the path is healthy — that hop is simply quiet.- Asymmetric routing means the return path can differ from the forward path, so a hop's RTT reflects the full round trip, not just the outbound leg. This is why traceroute latency can look strange even on a healthy path.
- Latency rising AND staying high from a specific hop onward — that's your real signal. Note whose network that hop belongs to.
Traceroute vs Ping vs MTR
These three tools are complementary, and serious diagnosis uses them together:
| Tool | Answers | Best for |
|---|---|---|
| Ping | Is the destination reachable, how fast, how much loss? | Quick health check of the endpoint |
| Traceroute | What's the path and where does it degrade? | Locating where a problem is |
| MTR | Both, continuously, with per-hop loss stats | Diagnosing intermittent problems |
MTR (my traceroute) is the power tool: it runs traceroute repeatedly and aggregates the results, showing per-hop packet loss and latency over hundreds of probes. Because packet loss is intermittent, a single traceroute can easily miss it — MTR's continuous sampling is what reliably catches "hop 7 is dropping 4% of packets." When you're chasing a flaky, comes-and-goes problem, reach for MTR over a one-shot traceroute.
A Practical Diagnosis Workflow
When users report slowness or your monitoring flags latency or loss, work the path:
- Ping the destination to confirm there's a real problem and quantify it.
- Run MTR (or several traceroutes) to the same destination to see the full path and per-hop stats.
- Find the first hop where latency rises and stays high, or loss begins and continues to the destination. That's your suspect.
- Identify whose network that hop is on — your LAN, your ISP, a transit provider, or the destination's network — using the hostname/IP.
- Act on the evidence: fix it if it's yours; open a ticket with the MTR output if it's an ISP or provider, since concrete hop data gets problems taken seriously.
- Compare from multiple sources — if the path is clean from one location but bad from another, the issue is on a specific route, not the destination itself.
How Webalert Helps
Traceroute is a point-in-time diagnostic you run by hand; Webalert is the continuous monitoring that tells you when to run it and confirms the user impact:
- Multi-region checks that reveal when latency or reachability degrades from specific parts of the world — the signal that a network path, not your origin, is the problem.
- Continuous latency and packet-loss-style tracking so degradation surfaces as an alert instead of a user complaint, prompting a path investigation.
- Outside-in perspective that distinguishes "our server is fine but a route to it is broken" from a true origin outage — the same black-box view traceroute gives you, but always-on.
Webalert tells you something on the path went wrong and where in the world it's visible; traceroute and MTR then pinpoint the exact hop.
Summary
Traceroute maps the routers between you and a destination by exploiting the TTL field, giving you per-hop latency so you can see where a network problem lives — something ping alone can't tell you. The art is in reading it correctly: ignore isolated middle-hop spikes and * * * timeouts, and only trust a problem that persists all the way to the destination.
For intermittent issues, MTR's continuous per-hop loss stats beat a single traceroute every time. Combine ping (is it broken?), traceroute (where?), and MTR (how often?), always check from multiple locations, and bring hop-level evidence when escalating to a provider. Pair these on-demand tools with continuous outside-in monitoring, and you'll know both when a path degrades and exactly where to look.