What Is MTR? How to Run and Read an mtr Report

MTR (My Traceroute, originally Matt's traceroute) combines traceroute and ping. It finds every router between you and a destination, then keeps sending probes to each of them and keeps statistics. A traceroute is one snapshot of the path; an mtr report is a hundred of them, summarised per hop. This guide covers how to install it, the options that matter, and a real report from our servers, read column by column.

Install mtr

System	Install	Run
Debian, Ubuntu	sudo apt install mtr-tiny (text only) or mtr	mtr example.com
Fedora, RHEL, Rocky	sudo dnf install mtr	mtr example.com
macOS	brew install mtr	sudo mtr example.com
Windows	WinMTR, a separate program with similar columns, or mtr inside WSL 2	Start WinMTR, enter the host

On macOS, Homebrew puts mtr in its sbin folder, which is not always on the PATH, and it needs sudo to send its probes. Without options, mtr opens a live screen that refreshes every second (press q to quit). For anything you want to keep or send, use report mode, which runs a fixed number of cycles and prints the result once:

mtr -rwz -c 100 example.com

The options worth knowing

Option	What it does
-r	Report mode: run, then print a table you can paste anywhere
-w	Wide report: full host names instead of truncated ones
-c 100	Number of probes per hop. 10 is a quick look; 100 is what you send to a provider
-z	Show the AS number of each hop, to see where one network hands over to the next
-n	No reverse DNS: faster, but you lose router names, which often contain a city code
-b	Show both the name and the IP address of each hop
-T -P 443	TCP probes to port 443, for networks that drop ICMP
-u	UDP probes instead of ICMP
-4, -6	Force IPv4 or IPv6
-i 0.5	Seconds between probes (1 by default; only root can go below 1)
--json	Machine-readable output

A real report, read column by column

We ran this on 7 October 2026 at 12:26 UTC from our server in Falkenstein, Germany (Hetzner), to a Vultr test host in New Jersey, with 100 probes per hop. Only the host name of our machine is shortened:

$ mtr -rwz -c 100 nj-us-ping.vultr.com
HOST: falkenstein                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    172.20.0.1                           73.0%   100    0.2   0.1   0.0   0.2   0.0
  2. AS24940  ex9k1.dc11.fsn1.hetzner.com           0.0%   100    4.7   1.0   0.3  15.1   1.7
  3. AS24940  core22.fsn1.hetzner.com               0.0%   100    0.8   0.7   0.3   1.7   0.2
  4. AS24940  juniper5.dc2.nbg1.hetzner.com         0.0%   100    3.0   5.2   2.8  65.6   9.2
  5. AS201011 ae12-499.nbg40.core-backbone.com      0.0%   100    3.2   3.0   2.7   3.3   0.1
  6. AS201011 ae7-2093.nyk10.core-backbone.com      0.0%   100   86.6  86.7  86.5  87.0   0.1
  7. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  8. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
  9. AS???    ???                                  100.0   100    0.0   0.0   0.0   0.0   0.0
 10. AS20473  66.55.138.149.vultrusercontent.com    2.0%   100   85.7  85.9  85.6  87.3   0.2
 11. AS20473  108.61.149.182.vultrusercontent.com   0.0%   100   86.2  86.4  85.9 107.1   2.1

• Loss%: the share of probes to that hop that got no answer. Here it reads 73% at hop 1 and 2% at hop 10, yet 0% at the destination. None of it is real loss (see below).
• Snt: probes sent to each hop, 100 here.
• Last, Avg, Best, Wrst: round-trip times in milliseconds for the last probe, the average, the fastest and the slowest. Best is the closest to what the path physically allows: 85.9 ms to New Jersey.
• StDev: how much the times vary, i.e. jitter. 0.1 to 0.2 ms on most hops: a quiet path.
• AS (from -z): the network that owns each address. Hops 2 to 4 are Hetzner (AS24940), hops 5 and 6 Core-Backbone (AS201011), hops 10 and 11 Vultr (AS20473). The handovers between them are where congestion usually shows, when there is any.
• Names: router names often carry a city. Hop 5 is nbg40 (Nuremberg) at 3 ms and hop 6 is nyk10 (New York) at 86.7 ms: the Atlantic crossing, in one line.

Three things in that report that look wrong but are not

1. Loss at a hop that does not continue. Hop 1 (the gateway of the container the test runs in) drops 73% of its answers, hop 10 drops 2%, and every hop after them answers everything. Routers answer probes in software, at low priority, and many limit how many answers they send per second. Traffic going through them is not affected.
2. A slow hop followed by fast ones. Hop 4 averages 5.2 ms with a worst case of 65.6 ms, while hop 5, right after it, never exceeds 3.3 ms. The router took its time to answer some probes; it did not delay the packets it forwarded.
3. Silent hops. Hops 7 to 9 never answer (???, 100%). They are routers configured not to reply. Since hops 10 and 11 answer, packets clearly pass through them.

The rule that follows: loss or latency only counts if it starts at a hop and continues to the destination. If hop 6 showed 15% loss and hops 7 to 11 showed the same, the problem would start at hop 6 or on the link just before it. A spike that disappears at the next hop is the router, not the path.

The same report run the same minute to Singapore shows these effects even more clearly: one Arelion router in Hamburg answered only 47% of the probes, another in Singapore 18%, with a worst time of 381.6 ms, and the destination answered 100% of them in 165.5 ms on average.

How many probes, from where, and when

• 10 probes are enough to see the path. 100 are needed to measure loss: with 10 probes, a 1% loss shows up as 0% most of the time.
• Run it while the problem is happening. An mtr taken an hour later shows a healthy path and proves nothing.
• Run it from more than one place. The same New Jersey host, measured the same minute from our server in Gravelines, France (OVHcloud), answered in 71.7 ms instead of 86.4 ms: OVH carries the traffic on its own network to New York and hands it to Vultr at the NYIIX exchange, while from Falkenstein it goes through Core-Backbone. Same destination, two routes, 15 ms apart.
• Remember the return path. Every time in the report is a round trip, and the way back can be a different route that mtr cannot see. If you can, run mtr from the other end as well.

Sending an mtr report to your provider

• Use mtr -rwzb -c 100: the report, full names, AS numbers and IP addresses.
• Write down the date, the time with its time zone, your public IP and the destination.
• If ICMP is filtered somewhere on the path, add -T -P 443 and say so.
• Point to the first hop where loss or latency starts and stays until the end, not to the hop with the biggest number.

mtr, traceroute and ping

Tool	What it measures	Default probe	Best for
ping	Round trip and loss to the destination only	ICMP echo	Is it up, how fast, how stable
traceroute	The path, three probes per hop, once	UDP on Linux and macOS, ICMP on Windows (tracert)	Seeing the route
mtr	The path, with loss and latency statistics for every hop	ICMP (UDP or TCP on request)	Intermittent problems, evidence for a provider

On Windows without WinMTR, the built-in pathping does something similar in two passes: a trace, then about 25 seconds of probes per hop. For the differences between the first two tools, see traceroute vs ping; for every system's traceroute command, see the traceroute command on Windows, Mac and Linux.

When you cannot run it yourself

Office networks often block the probes, phones cannot run mtr, and a test from your own connection says nothing about the path from elsewhere. TraceMapper runs the same measurement from our servers and from more than 30 locations, puts each hop on a map with its latency, loss and network, and keeps the result as a link you can send. To find where a path actually degrades, see how to identify network bottlenecks.