traceroute shows the path once. ping shows one end. mtr keeps probing every hop on the path and keeps score.
See loss and latency at every hop, tell real loss from routers that rate-limit replies, and use report mode for tickets. mtr sends probes with rising TTLs, like traceroute, and repeats them every second, like ping. Each row is a router on the path, with its loss and round-trip times so far. The examples use IP addresses (1.1.1.1 and 8.8.8.8 are public DNS resolvers) and were run with mtr 0.95 on Debian 13.
install
# mtr-tiny is the terminal-only build. The mtr package adds a GTK window
sudo apt install mtr-tiny
examples
# Live view: one row per hop, updated every second. d changes the display, r resets the counts, q quits
mtr 1.1.1.1
# Report for a ticket: 100 probes per hop, numeric addresses, full-width host column, then exit
mtr -rwn -c 100 8.8.8.8
Start: 2026-10-28T09:48:06-0700
HOST: lab Loss% Snt Last Avg Best Wrst StDev
1.|-- 172.30.0.1 1.0% 100 0.2 0.4 0.1 0.8 0.2
2.|-- 10.0.7.18 0.0% 100 0.7 0.9 0.5 2.4 0.3
3.|-- 3.236.62.77 0.0% 100 6.2 15.8 1.5 110.1 24.1
4.|-- 240.0.56.96 0.0% 100 1.1 1.3 0.9 4.8 0.4
5.|-- 242.0.227.215 0.0% 100 1.7 3.0 1.0 24.6 3.5
6.|-- 240.3.180.74 0.0% 100 2.4 2.8 2.1 7.1 0.7
7.|-- 99.82.181.23 0.0% 100 3.2 2.8 2.0 5.0 0.7
8.|-- 192.178.45.33 0.0% 100 2.8 2.7 1.7 9.2 0.8
192.178.45.29
192.178.45.31
9.|-- 142.251.70.85 0.0% 100 2.4 2.3 1.8 2.9 0.2
209.85.252.17
142.251.67.235
10.|-- 8.8.8.8 0.0% 100 2.3 2.2 1.7 6.8 0.5
A 100-probe report takes about 100 seconds. Times are milliseconds. The indented addresses under hops 8 and 9 are other routers that answered for the same hop: the path is load-balanced there. -n skips reverse DNS, which is faster and shows the addresses the other side will ask for anyway.
# Pick the columns: loss, sent and dropped, then last, best, average and worst
mtr -n -r -c 10 -o "LSD NBAW" 8.8.8.8
# JSON for scripts: print only the hops that lost probes
mtr -j -n -c 10 1.1.1.1 | jq -r '.report.hubs[] | select(."Loss%" > 0) | "\(.count) \(.host) \(."Loss%")%"'
loss at a middle hop
This is the run from the column example above. Two hops show loss, and hop 6 shows round trips over a second:
HOST: lab Loss% Snt Drop Last Best Avg Wrst
1.|-- 172.30.0.1 10.0% 10 1 0.3 0.2 0.3 0.6
2.|-- 10.0.7.18 0.0% 10 0 0.8 0.6 0.9 1.2
3.|-- 244.5.8.239 0.0% 10 0 9.9 1.8 30.4 85.1
4.|-- 240.6.88.1 0.0% 10 0 0.8 0.8 1.1 1.3
5.|-- 242.19.39.193 0.0% 10 0 6.4 1.2 2.4 6.4
6.|-- 240.3.180.75 10.0% 10 1 1399. 230.3 1063. 1501.2
7.|-- 72.14.203.158 0.0% 10 0 2.1 1.6 2.1 2.4
8.|-- 192.178.44.213 0.0% 10 0 3.6 2.1 2.8 4.0
9.|-- 142.251.67.235 0.0% 10 0 2.0 2.0 2.3 2.8
142.251.64.103
209.85.252.19
10.|-- 8.8.8.8 0.0% 10 0 2.2 1.8 2.2 2.6
Nothing is wrong with this path. Every probe that went past hop 6 came back, and the destination answered all 10 in about 2 ms. Loss shown only at a middle hop, and not carried to the later hops, is usually ICMP rate limiting, not real loss. A router forwards your traffic in hardware, but it builds the "time exceeded" reply that mtr counts in its slower control plane, and it limits how many of those it sends. Some routers also put those replies at the back of the queue, which is where hop 6's one-second times come from. The probes that reached hops 7 to 10 went through hop 6 without trouble.
Real loss starts at one hop and carries on to every hop after it, the destination included. If hop 4 showed 30% and every row below it showed about 30% too, that would be worth a ticket, and hop 4 (or the link just before it) is where to look. Read the destination row first: if it shows no loss, the path isn't losing your traffic, whatever the middle rows say.
pro tip
For a ticket, send mtr -rwn -c 100 output, not a screenshot of the live view, and say when it ran: the report starts with the time. Run it from both ends if you can. The return path is often different, and mtr only shows the way out.
honest limits
mtr can only show routers that answer. A ??? row with 100% loss is a hop that doesn't reply to probes at all, which says nothing about traffic through it. The -T (TCP) and -u (UDP) probe modes help when ICMP is filtered, but they behave differently behind proxies and firewalls: on our test machine a TCP trace stopped at the first hop, because a proxy answered for the destination. The Debian package lets you run mtr without sudo. Other installs may need it. Everything on this page was run on Debian 13 with mtr 0.95. Homebrew has an mtr formula (0.96 at the time of writing), but this page wasn't tested on macOS.