How to run MTR and interpret loss and latency
Run MTR on Linux, macOS and Windows, select the right destination and protocol, collect a useful sample and interpret hops without false network attribution.
Updated 7/30/20264 min read
Generate a useful report
Install MTR from your operating system repository and target the affected IP or hostname. Report mode produces output that is easy to attach to a support case.
- 01Choose the originRun from the client or server experiencing the symptom.
- 02Capture contextRecord timezone, date, source/destination IP and whether the issue was active.
- 03RepeatCompare incident and healthy windows and measure the reverse route when possible.
mtr -4 -rwzc 100 destination.exampleRelated guide: Argentina VPS latency: how to measure it
Read columns without jumping to conclusions
Loss% reports missing MTR probe responses; Avg, Best, Wrst and StDev summarize latency. Routers may rate-limit ICMP to themselves while forwarding traffic normally.
| Read columns without jumping to conclusions | What it indicates | What it does not prove alone |
|---|---|---|
| Loss% | Unanswered probes at that hop | End-to-end loss when later hops are healthy |
| Avg/Wrst | Average and worst observed latency | Permanent congestion from a short sample |
| StDev | Variation in responses | Application jitter without its protocol |
When to escalate
Attach the report, IPs, timestamp, symptom and an application test. Loss or latency beginning at one point and persisting through every later hop including the destination is stronger evidence.
Frequently asked questions
How many MTR cycles should I run?
One hundred cycles is a useful starting sample, while intermittent faults may need longer. Always record duration and timing.
Does MTR replace a PCAP?
No. MTR observes route and probe responses; a PCAP records packets from a specific flow. They answer different questions.