Reading a Traceroute Without Fooling Yourself
Traceroute output is misread more often than any other diagnostic on this site, and the misreadings are confident. Most of them come from treating the per-hop timings as a measurement of that hop, which is not what they are. Getting this right turns traceroute from a source of plausible wrong conclusions into the tool that locates a problem.
What the numbers actually measure
Each timing is the round trip from you to that hop and back — not the time spent at that hop, and not the time between it and the previous one. That distinction matters because it means latency is cumulative down the list: a hop showing 90ms when the previous showed 30ms has not added 90ms, it has added 60ms, and only if the return path is symmetric, which it frequently is not.
The practical consequence: read the shape of the column, not individual values. A step increase that persists to the destination is meaningful. A single elevated hop with normal values after it is not.
The high-latency hop that means nothing
Routers generate the responses traceroute depends on as a low-priority task, handled by a control-plane processor that is busy doing other things. A hop reporting 200ms while every subsequent hop reports 40ms is telling you the router was slow to answer a question about itself, not that traffic passing through it was delayed. Traffic through that hop is demonstrably fine, because everything after it is fast.
This single pattern accounts for the majority of misdiagnoses, and it is the one to internalise: if the hops after it are healthy, that hop is healthy.
The hop showing 100% loss that also means nothing
Same cause, more extreme. Plenty of routers are configured never to respond about themselves while forwarding traffic perfectly. A hop showing complete loss with the destination responding normally is a router declining to answer, not a broken link — if it were broken, nothing past it would work.
The rule that resolves it: loss at one hop that disappears at later hops is cosmetic; loss that begins at a hop and continues to the destination is real. You cannot apply that rule from a single traceroute, which is why a tool that samples repeatedly is the right one for a loss investigation.
Asymmetry, and why it makes you doubt yourself
The return path is often not the forward path, and traceroute only shows you the forward one. This means a problem that appears at a particular hop may actually be on the return leg from somewhere entirely different, and it explains why a traceroute from the other end can look completely unlike yours. When both parties run one and the results disagree, that is normal and neither is wrong.
It also means you cannot conclusively locate a one-directional problem from your side alone. If the evidence points that way, a traceroute from the far end is not optional.
What a route change looks like
Comparing today's path to a recorded one from last month is where traceroute earns its place. A path that gained three hops and crossed a continent it did not previously cross is a routing change — a peering arrangement lapsed, a transit policy changed — and the added latency is entirely explained by geography rather than by anything failing. Nothing is broken and everything is slower.
Without a recorded baseline this is undiagnosable, because a route that looks circuitous is indistinguishable from one that was always like that. This is the single strongest reason to capture paths on a schedule rather than only during incidents.
Making the case to someone else
When the faulty hop belongs to a transit provider, the actual task is persuading them, and that is an evidence problem. One screenshot during an incident is easy to dismiss as a transient or as a control-plane artefact — correctly, given everything above. A fortnight of recorded per-hop loss beginning consistently at one hop and persisting to the destination is a different conversation, and it is one you can only have if something was recording before you needed it.