A hop
One router along the way. The number is the TTL that elicited its reply, not a position in a fixed route — the path can differ between packets.
Routers are not obliged to answer a traceroute, and a great many are configured not to or rate limit their replies. A gap in the middle of a path whose destination still answers means one router stayed quiet — not that traffic was lost there. Reading those gaps as packet loss is the single most common way traceroute output misleads people.
One router along the way. The number is the TTL that elicited its reply, not a position in a fixed route — the path can differ between packets.
There and back to that hop. It is not the time to get to that hop, and it includes whatever delay the router took to generate its reply.
That router did not answer. Extremely common, deliberate on many networks, and not a measurement of anything.
The return path is a different length from the outbound one. Normal on the internet, and it means one-way delay is not half the round trip.
Only the final hop tells you about reachability. If the destination answers, the path works, whatever happened in the middle. If it does not answer, that is often also deliberate — Cloudflare and Google both drop these probes, so a trace to 1.1.1.1 ends in silence while the resolver works perfectly.
A latency rise usually means distance, not congestion. A jump of seventy to a hundred milliseconds between consecutive hops is what a transatlantic link looks like. It is worth investigating when the rise is not matched by a change of geography, or when it fluctuates between runs — a stable high figure is just a long cable.
A router that reports a high round-trip time is not necessarily slow. Generating an ICMP reply is low-priority work on most hardware, so a busy router answers traceroutes late while forwarding real traffic promptly. If hop seven shows 200 ms and hop eight shows 60 ms, hop seven is not the bottleneck — it is deprioritising your probe.
This trace runs from our server, so it shows our path to the destination and not yours. For a problem reaching a specific service from a specific network, a trace run from that network is the one that matters — this is useful as a comparison, to establish whether the path is bad for everyone or only for you.
Usually because the destination does not answer these probes. Many hosts and most large services drop them deliberately. If the service responds to an ordinary connection — a web request, a ping, a port check — it is reachable, and the trace ending early says nothing to the contrary.
No. It means that router chose not to answer, which a great many are configured to do, and others rate limit so only some probes get a reply. Real packet loss affects the hops after it as well, and shows up at the destination. A single silent hop followed by replies is not loss.
That router is generating its reply slowly, not forwarding slowly. Producing ICMP responses is low-priority work on router hardware, so a busy device answers probes late while handling real traffic normally. The figures that matter are the ones that persist to the end of the path.
Because it starts somewhere else. This runs from our server; yours runs from your network. Routing is chosen per-network and per-direction, so the two will rarely match. That is exactly what makes the comparison useful when you are trying to tell a local problem from a general one.
The reply came back over a path with a different number of hops than the outbound one. Internet routing is chosen independently in each direction, so this is normal. Its practical consequence is that you cannot treat one-way delay as half the round-trip time.
A site that answers slowly at 3pm, a certificate that expires on a Sunday, a redirect chain that grew a hop nobody noticed. We monitor and operate infrastructure around the clock, which is the difference between knowing and being told by a customer.