MTR (My Traceroute) is what you get from combining ping and traceroute rather than choosing between them: it discovers every router between here and a destination, then pings each one repeatedly for the length of the run — live loss percentage and round-trip time, per hop, not a single snapshot. Where a plain traceroute samples the path once, MTR keeps watching it.
How MTR Works
The first pass is exactly what traceroute does — discover every router along the path using TTL-expiry probes. From there MTR does something traceroute never does: it pings every discovered hop again, and again, for the whole run, building up real statistics — sent, received, loss%, and the last/average/best/worst round-trip time — at every single hop, not just the destination.
How an MTR run works
Reading the Table
- Loss% — the share of probes to that specific hop that never got a reply. 0% at every hop is ideal; loss that appears at one hop and persists through every hop after it is real and worth investigating.
- Sent — how many probes this hop has been sent so far in the run.
- Last / Avg / Best / Worst — round-trip time in milliseconds for that hop specifically: the most recent probe, the running average, and the fastest and slowest replies seen during the run.
Why a Hop Can Show Loss With Nothing Actually Wrong
This is the single most common misreading of an MTR table. Many routers, particularly inside ISP backbones, are configured to deprioritize or rate-limit the ICMP replies MTR's probes depend on — generating one costs the router real CPU time, so operators frequently throttle that traffic specifically while continuing to forward ordinary traffic through the same router without any issue. The tell is what happens at the hops after the lossy one: if they show 0% loss, the path itself is fine — the traffic reaching the destination never took the shortcut a diagnostic probe does. Loss that shows up at a hop and then persists at every hop downstream of it is the pattern that actually indicates a problem.
MTR vs. Ping vs. Traceroute
Ping answers one question — is the destination reachable, and what's the round-trip time — with no visibility into the path itself. Traceroute reveals the path, but only samples each hop once or twice, which can miss intermittent issues entirely. MTR is the two combined: the path traceroute reveals, with the repeated sampling that makes ping's statistics meaningful, applied to every hop instead of just the destination. The tradeoff is time — a single ping or trace finishes in a few seconds; a useful MTR run needs to keep sampling for a while to catch anything intermittent.
When to Use MTR
- A connection feels intermittently bad — occasional stutters or drops — that a single ping or traceroute run doesn't reproduce.
- Deciding whether reported loss or latency is a real network problem or just one router along the path deprioritizing diagnostic probes.
- Narrowing down where, specifically, along a path loss or latency actually starts, before escalating to an ISP or hosting provider.
- Getting both a path map and reachability statistics in one pass instead of running Ping and Traceroute separately and correlating them by hand.
Frequently Asked Questions
What is MTR?
MTR (My Traceroute) combines ping and traceroute: it discovers every router along the path to a host, then pings each one on a rolling basis for the whole run, showing live loss percentage and last/average/best/worst round-trip time per hop — not just once, but continuously.
How is MTR different from running ping and traceroute separately?
A single traceroute run only probes each hop once or twice, which can easily miss loss that only shows up sometimes. MTR keeps pinging every hop for the length of the run, so intermittent loss — a router that drops one packet in twenty — actually shows up as a percentage instead of getting missed entirely.
Why does one hop show packet loss while every hop after it shows none?
That's usually the router at that hop deprioritizing or rate-limiting the ICMP probes MTR depends on, not a real problem — it costs a router real CPU time to reply to every probe, so many routers are configured to deprioritize that traffic while still forwarding normal traffic through the same router without issue. Loss that also shows up at every hop after it is the real signal worth investigating.
How long does an MTR run take?
This tool runs a fixed, bounded number of cycles — about 15–20 seconds total — rather than running indefinitely the way MTR does on a command line until you stop it. That's long enough to catch intermittent loss a single traceroute pass would miss, without holding a live probe open forever.
Run MTR against any hostname or IP address to see live per-hop loss and latency.