How to run and read an MTR report (packet loss and latency)

MTR combines ping and traceroute: it sends packets to every hop on the path again and again and shows loss and latency for each one. It is the single most useful report for slow or unstable connections, but it is also easy to misread. This guide shows how to run it and what the numbers really mean.

Before you start

• Linux: sudo apt install mtr-tiny (Debian/Ubuntu) or sudo dnf install mtr (AlmaLinux/Rocky).
• macOS: brew install mtr.
• Windows: install WinMTR (open source) and run it as a normal program.
• The domain or IP you are having trouble with, and your public IP from /tools/ip-checker.

Run an MTR report

1. Run a report with 100 cycles so the numbers are meaningful:

mtr -rwbzc 100 example.com

Flags: -r report mode, -w wide hostnames, -b show IPs too, -z show AS numbers (which network owns each hop), -c 100 send 100 probes.

2. If the problem only affects one service, test with TCP to its port instead of ICMP, because some networks treat ICMP differently:

sudo mtr -rwbz -T -P 443 -c 100 example.com

3. Ideally, also run MTR in the reverse direction, from the server back to your public IP. Problems are often on the return path, which can be completely different. Our support team can run this for you.

Understand the columns

Rule 1: loss only counts if it continues to the end

Routers give low priority to answering probes addressed to themselves. A hop can show 30% loss while every hop after it shows 0%; that is ICMP rate limiting, not real loss. Real packet loss starts at a hop and carries on through every following hop down to the destination.

  6. be2.fra.example-transit.net   40.0%  100  12.1  12.4  11.9  14.0  0.4
  7. core1.fra.provider.net         0.0%  100  12.6  12.8  12.3  15.1  0.5
  8. server.example.com             0.0%  100  12.9  13.0  12.6  15.8  0.5

Above, hop 6 is just rate limiting: the destination shows 0% loss. Compare with real loss:

  6. be2.fra.example-transit.net    8.0%  100  12.1  12.4  11.9  14.0  0.4
  7. core1.fra.provider.net          9.0%  100  12.6  12.8  12.3  15.1  0.5
  8. server.example.com              8.0%  100  12.9  13.0  12.6  15.8  0.5

Rule 2: latency only counts if it stays higher

The same logic applies to latency. A single hop with a high average while later hops are low again is a slow-answering router, not a slow path. A jump that stays for all remaining hops is real. Large jumps are often simply distance: crossing the Atlantic adds roughly 70–90 ms, and Europe to Singapore 150 ms or more. See what is latency.

Rule 3: watch the worst and StDev columns

An average of 20 ms with a worst of 400 ms and a high StDev means jitter: bursts of congestion. That hurts SSH, RDP, voice and games more than a steady higher latency does.

Where the problem usually is

• Loss from hop 1 or 2: your own Wi-Fi, router or ISP line. Try a cable, restart the router, contact your ISP.
• Loss starting inside a transit network (the AS changes): congestion between providers. Send both directions of MTR to your host so they can raise it with the carrier or reroute.
• Loss only on the last hop: the server itself or its firewall rate limiting. Check with a TCP MTR to the service port.

Troubleshooting

• Every hop after a point shows ???: the destination or a firewall blocks the probe type. Use -T -P 443 for a TCP trace.
• WinMTR shows nothing: run it from a network that allows ICMP, or use tracert plus pathping as a fallback.

When you open a ticket, paste the full text report, the time it was taken and your public IP.

Next steps

• Diagnose problems with ping, traceroute, dig and curl
• Choose the best server location for your visitors
• Speed test a server: bandwidth vs throughput