Online Traceroute
Discover every router between our servers and a destination, with the latency measured at each hop. Traceroute maps the path packets actually take, which is what turns "the connection is bad" into "the connection is bad starting at this specific network".
It works by sending packets with deliberately short time-to-live values. Each router along the way decrements the TTL, and the one that drops it to zero reports back — revealing itself and its distance from the sender.
Reading the output
- Hop number — position along the path. Hop 1 is the first router after the sender.
- Hostname and IP — often encodes the operator, city and link type, which is how you tell whose network a hop belongs to.
- Latency — round trip to that hop, not the cumulative time to the destination.
- Asterisks — that hop did not reply. Usually policy rather than failure.
The four things people misread
Loss at one hop that clears afterwards is not a fault. Routers rate-limit replies about themselves while forwarding transit traffic untouched. If hop 6 shows 40% loss and hops 7, 8 and the destination all show zero, hop 6 is fine — every packet that reached hop 7 travelled through it.
A latency jump between two hops is usually distance. A 70 ms increase between consecutive hops normally means a long-haul or submarine link, not congestion. What matters is whether the elevated figure persists to the destination.
Asterisks are usually policy. Many backbone routers disable ICMP responses, and hops inside an MPLS tunnel are invisible by design. They only indicate a problem when the silence continues all the way to a destination that never answers.
The path is not stable. Networks load-balance across equal-cost routes, so consecutive runs can legitimately differ. Run it more than once before concluding anything about the route.
What traceroute cannot show you
It measures the path away from the sender only. Internet routing is asymmetric, so return traffic often takes a completely different set of networks — and a fault on that return path is invisible here. That is why a clean traceroute does not rule out a real problem, and why testing the return path resolves a category of cases where everyone's tests look fine.
It also samples only a few packets per hop. An intermittent fault that affects 5% of traffic can easily be missed, which is what MTR exists to catch.
Turning a trace into something an ISP will act on
Support desks receive a great many traceroutes that show nothing wrong. What gets a ticket escalated is loss that begins at a hop and continues through every hop after it including the destination, reproduced at several times of day, alongside a control test to a different network showing the problem is not universal. Mid-path loss percentages are the most common reason a ticket is closed without investigation.