Ping can show that ICMP RTT or apparent loss changed, but not where. Traceroute adds evidence about responding hops and path changes. It does not prove that one router adds a measured amount of one-way delay, because each value is a round trip and forward/return paths can differ.
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 routers that return TTL-expiry responses for a sequence of probes. Equal-cost routing can send probes over different forward paths, and hidden or non-responding routers may not appear. Run traceroute example.com (macOS/Linux) or tracert example.com (Windows) and treat the numbered output as a sampled path, not a complete topology map.
For each responding hop you typically see an IP/hostname and three probe round-trip times—not the processing delay added by that router alone. The pattern helps investigate questions ping cannot:
- 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) repeats probes and aggregates per-hop reply rate and RTT. It is better than one trace for intermittent patterns, but apparent loss at an intermediate hop can still be control-plane rate limiting. Treat it as forwarding loss only when degradation persists to the destination or is confirmed with application/transport evidence.
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 where latency rises and remains elevated, or apparent loss continues through the destination. Treat that segment as a suspect, then confirm with endpoint traffic and traces from another source or the reverse direction.
- 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.
Outside-in monitoring shows where impact is visible; traceroute and MTR narrow the suspect path segment rather than proving one exact faulty router.
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.