What MTR Is and How to Run It
MTR ("My Traceroute," originally Matt's Traceroute) maps every router hop between your computer and a target, then keeps pinging all of them continuously, updating a live table. Where a traceroute gives you one snapshot, MTR gives you running statistics that expose intermittent loss and unstable hops a single pass would miss. For the command-line reference and install options, see the mtr command guide.
# Live, updating view (q or Ctrl+C to quit)
mtr 1.1.1.1
# A fixed-length report you can save and share with your ISP
mtr --report --report-cycles 100 1.1.1.1 # macOS/Linux
mtr -r -c 100 1.1.1.1
# Windows: use WinMTR (GUI equivalent)The Columns, One by One
A typical report row looks like this:
HOST: yourpc Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.8 0.9 0.7 2.1 0.2
2.|-- 10.0.0.1 0.0% 100 9.4 9.8 8.9 14.2 0.9
3.|-- isp-core.example.net 0.0% 100 11.1 12.0 10.2 41.3 3.1
4.|-- ??? 100.0% 100 0.0 0.0 0.0 0.0 0.0
5.|-- edge.example.net 0.0% 100 23.5 24.1 22.8 55.0 4.2
9.|-- one.one.one.one 0.0% 100 23.9 24.4 23.1 60.2 5.0| Column | What it tells you |
|---|---|
| Hop / HOST | Each router on the path, in order; hop 1 is your own gateway, the last is the destination |
| Loss% | Percentage of probes to that hop with no reply — the headline number, but read with care (below) |
| Snt | How many probes have been sent so far — bigger is more trustworthy |
| Last | Round-trip time of the most recent probe, in ms |
| Avg | Average latency to that hop — the number to watch for where delay is added |
| Best / Wrst | Fastest and slowest round trips seen — a huge gap signals instability |
| StDev | Standard deviation — high values mean jittery, inconsistent latency at that hop |
The One Rule That Prevents False Alarms
This is where most people misread MTR. In the example above, hop 4 shows 100% loss — alarming until you notice hops 5 and 9 show 0% loss. If a hop were truly dropping your traffic, every hop after it would lose traffic too. A single lossy hop with clean hops beyond it means that one router is simply rate-limiting or refusing the ICMP probes MTR uses to measure it, while happily forwarding your real data. This is normal and harmless.
The rule: loss only matters when it appears at a hop and persists through every hop after it, all the way to the destination. Loss that appears mid-path and clears further along is cosmetic. Read the report from the bottom up — start at the destination row, and if its Loss% is 0, your path is healthy regardless of what middle hops show.
Diagnosing by Where the Numbers Change
| Pattern | What it means |
|---|---|
| Loss begins at hop 1 (your gateway) and continues | Problem inside your home — Wi-Fi, cable, or your router. Test on Ethernet. |
| Hops 1–2 clean; loss starts at hop 3–4 and continues to the end | Problem at your ISP's edge — bring this report to support |
| Avg latency jumps sharply at one hop, then stays high | That hop is congested or a long-distance link; latency added there carries downstream |
| High StDev / big Best–Wrst gap at the destination | Jittery path — bad for calls and gaming even if average looks fine |
| Only the destination shows loss, every hop before is clean | The target server itself is overloaded or de-prioritising pings — not your connection |
Latency vs Loss — Read Both
MTR shows two different health signals and they fail independently. Loss% tells you packets are disappearing; even 1–2% that persists to the destination will stutter calls and games. Avg / StDev tell you about delay and its consistency; a path with 0% loss but a 200 ms average or a wild Best–Wrst spread will still feel sluggish and unstable. A genuinely healthy result is 0% loss at the destination, a reasonable average for the distance, and a low StDev. For the deeper meaning of these numbers in isolation, see how to read ping output.
Using MTR as Evidence
A saved MTR report is the most persuasive thing you can hand an ISP, because it points to the exact hop where their network starts dropping traffic. Run mtr --report -c 200 8.8.8.8 > mtr-report.txt during the problem, note the time, and attach it. Pair it with the broader procedure in test for packet loss and documenting the problem for your ISP so the ticket is hard to dismiss.
Frequently Asked Questions
Why does MTR show loss at one hop but not the final one?
Because that middle router is rate-limiting the ICMP replies MTR uses to measure it, not actually dropping your traffic. Routers prioritise forwarding real data over answering pings. If a hop shows loss but every hop after it — including the destination — shows none, the loss is cosmetic. Only loss that appears at a hop and continues through to the destination is real.
How long should I let MTR run?
At least 100 cycles so the percentages are statistically meaningful — a 10-packet sample makes a single drop look like 10% loss. For an intermittent problem, run it for several hundred cycles or use report mode with --report-cycles 500 during the period the issue occurs, so the average reflects reality rather than one unlucky moment.
What is the difference between MTR and traceroute?
Traceroute sends a few packets to each hop once and prints a snapshot. MTR keeps sending continuously and updates running statistics — loss percentage, average latency, and jitter per hop — so it reveals intermittent loss and unstable hops that a one-shot traceroute would miss entirely.
The hops show names like "???" — is that a problem?
No. "???" or a blank host name just means that router did not return a reverse-DNS name or did not reply to the probe at that moment. It does not affect the loss or latency measurement. Judge the hop by its numbers, not by whether it resolved to a friendly name.