Ping tells you a host is reachable. Traceroute tells you the path. The mtr command does both at once, continuously, in a live table that updates every second. When someone reports “the VPN is slow” or “the site keeps dropping”, this is the first tool I reach for, because it shows exactly which hop on the route is losing packets or adding latency. It ships on almost every distribution and takes about two minutes to learn.
The name stands for My Traceroute. It sends a stream of packets with increasing TTL values, exactly like traceroute, but keeps sending them in a loop and tracks loss and latency statistics per hop over time. A single traceroute run can miss intermittent problems. Ten minutes of mtr rarely does.
What the mtr Command Shows You
Run it against any host and you get a table with one row per hop. The columns that matter: Loss% (percentage of probes that hop failed to answer), Snt (probes sent), Last, Avg, Best, Wrst (latency in milliseconds), and StDev. A high StDev means jitter, which hurts VoIP and SSH sessions even when average latency looks fine.
One thing beginners misread constantly: loss shown at a middle hop that disappears at later hops is not real loss. Routers deprioritize ICMP replies addressed to themselves while forwarding your traffic just fine. Loss only matters when it starts at one hop and continues all the way to the destination.
Installing mtr
On Debian and Ubuntu, install the text-mode package:
sudo apt install mtr-tinyThe full mtr package pulls in GTK for a graphical mode nobody uses on servers. On Fedora it is sudo dnf install mtr, on Arch sudo pacman -S mtr, and on Alpine apk add mtr. Source code lives in the mtr GitHub repository.
10 Practical mtr Command Examples
1. Run Your First mtr Command Trace
mtr example.comThis opens the live curses interface. Let it run for at least 100 probes before drawing conclusions. Press q to quit, d to cycle display modes, and p to pause.
2. Generate a Text Report for Tickets
mtr -rwbz -c 100 example.comReport mode is what you paste into a support ticket. -r produces a report instead of the live view, -w uses wide output so hostnames are not truncated, -b shows both hostnames and IPs, -z adds AS numbers, and -c 100 sends 100 probes per hop. The command exits when done and prints the summary table.
3. Use TCP Probes When ICMP Is Filtered
sudo mtr --tcp -P 443 example.comPlenty of firewalls drop ICMP but pass TCP to port 443. TCP mode makes the mtr command test the same path your HTTPS traffic actually takes, which matters because routers sometimes route ICMP and TCP differently. There is also --udp for testing DNS or VoIP paths.
4. Skip DNS Lookups for Faster Output
mtr -n example.comReverse DNS lookups slow the mtr command display down and sometimes hang on hops with broken PTR records. -n shows raw IPs only. I use this by default and only turn names back on when I need to identify a carrier.
5. Force IPv4 or IPv6
mtr -4 example.com
mtr -6 example.comDual-stack hosts often take completely different routes over IPv4 and IPv6. If users on one network complain and others see no problem, compare both. I have found broken IPv6 peering this way more than once while the IPv4 path was clean.
6. Control Probe Count and Interval
mtr -r -c 300 -i 0.5 example.com-i 0.5 sends a probe every half second instead of every second, and -c 300 collects 300 rounds. That gives you 300 samples per hop in two and a half minutes, enough to catch intermittent loss that a quick 10-probe run would miss. Intervals under one second require root.
7. Export mtr Command Results as JSON or CSV
mtr -rw --json -c 50 example.com > path.json
mtr -rw --csv -c 50 example.com > path.csvThe JSON output feeds monitoring pipelines nicely. I run a cron job that traces a few critical destinations hourly and stores the JSON, so when a customer says “it was slow yesterday at 3pm” there is real data to check instead of guesswork. Pair it with jq for parsing and the whole thing scripts in ten lines.
8. Change Packet Size to Spot MTU Problems
mtr -r -c 50 -s 1400 example.com-s tells the mtr command to use a probe payload of that many bytes. If small probes pass and 1400-byte probes vanish at a specific hop, you are looking at an MTU or fragmentation issue, common on VPN and PPPoE links. Step the size up and down to find the exact threshold.
9. Limit the Hop Range
mtr -r -f 5 -m 15 example.com-f 5 starts probing at hop 5, skipping your own LAN and ISP access layer, while -m 15 caps the trace at 15 hops. Useful when the interesting segment is a transit provider in the middle and you do not want noise from either end.
10. Watch a Flapping Route in Real Time
mtr --displaymode 2 example.comDisplay mode 2 draws a scrolling histogram per hop, so a route that degrades every few minutes shows up as visible bands of loss. For long sessions I run it inside tmux on a monitoring box and check back later.
Reading mtr Command Output Without Fooling Yourself
Three rules keep the diagnosis honest. First, only trust loss that persists to the final hop. Second, latency jumps between hops are normal when the path crosses an ocean, so look at the destination’s Avg, not intermediate spikes. Third, remember the mtr command only sees the forward path. The return path can differ, and asymmetric routing produces confusing numbers. When results look strange, run a trace from the far end too.
When Not to Use the mtr Command
For packet-level inspection of what is inside the traffic, you want tcpdump instead. For a quick visual latency check against a single host with no path detail, gping is lighter. And bandwidth problems need iperf3, because mtr measures loss and latency, not throughput. The full option list is in the official mtr documentation and the man page.
Next time a route misbehaves, skip the ping-then-traceroute dance. One mtr report with 100 probes answers the question both of those tools only hint at, and it fits in a ticket comment.