MTR is a network diagnostic tool that combines traceroute and ping into one continuous measurement, showing packet loss and latency for every hop between a source and a destination. Originally called Matt’s traceroute and now commonly expanded as My traceroute, it is a standard instrument in network monitoring and troubleshooting on Linux, BSD and macOS, with WinMTR filling the same role on Windows.
Where traceroute takes a single snapshot of a path, MTR repeats its probes many times and aggregates the results. This turns an anecdotal path listing into statistics that reveal intermittent loss, unstable latency and routing changes.
How MTR measures a network path
MTR discovers the path by sending probes with increasing time-to-live values. The router at which the TTL reaches zero discards the probe and returns an ICMP Time Exceeded message, revealing its address and the round-trip time to it. The destination itself answers with an echo reply or, for UDP and TCP probes, with a port unreachable or a TCP response.
Unlike traceroute, MTR keeps cycling through all hops, by default once per second, and updates per-hop statistics after every round. In report mode, used for sharing results, it sends a fixed number of cycles, typically 10 by default and often 100 or more for meaningful loss figures, and then prints a summary table.
| Column | Meaning | How to read it |
|---|---|---|
| Loss% | Share of probes without a reply | Meaningful only if it persists to later hops |
| Snt | Number of probes sent | More probes give more reliable percentages |
| Last | Latency of the most recent probe | Shows the current state |
| Avg | Mean round-trip time | Baseline latency to that hop |
| Best and Wrst | Minimum and maximum latency | Wide spread signals congestion or queuing |
| StDev | Standard deviation of latency | Indicates jitter at that point |
Interpreting loss and latency correctly
The single most important rule is that loss at an intermediate hop matters only if it continues to the destination. Routers forward transit traffic in hardware but generate ICMP replies in their control plane, which is usually rate-limited and low-priority. A hop that shows 40 percent loss while every later hop shows 0 percent is simply deprioritizing replies, not dropping customer traffic.
The same logic applies to latency. A spike at one hop that does not carry through to later hops reflects slow ICMP generation, not a slow link. Genuine problems appear as a step in latency or loss that persists through all following hops, and the fault usually lies on the link just before the first affected hop.
| Pattern | Likely meaning | Action |
|---|---|---|
| Loss at one middle hop only | ICMP rate limiting on that router | Ignore |
| Loss starting at a hop and continuing | Real loss on or after that link | Report to the owner of that segment |
| Loss only at the final hop | Destination limits ICMP or filters probes | Repeat with TCP probes |
| Latency jump persisting to the end | Long physical distance or congestion | Compare with geography and time of day |
| Rows of question marks | Hops that never reply | Normal if later hops respond |
| Path alternating between addresses | ECMP or load balancing | Use fixed ports or the TCP mode |
Return paths complicate everything. The reply from each hop may travel a different route back than the probe took outward, so latency and loss can come from the reverse direction. Running MTR from both ends of the connection is the reliable way to locate asymmetric faults.
Probe types and useful options
MTR can send ICMP echo, UDP or TCP probes, and the choice determines whether firewalls along the path treat the measurement like the real traffic being investigated.
| Option | Effect | When to use |
|---|---|---|
| –report and -c 100 | Runs 100 cycles and prints a summary | Sharing results with providers |
| –tcp with -P 443 | Sends TCP SYN probes to port 443 | Firewalls block ICMP or the issue is HTTPS-specific |
| –udp | Sends UDP probes | Diagnosing VoIP or game traffic |
| -n | Disables reverse DNS lookups | Faster output and no DNS noise |
| -z | Shows the autonomous system number | Identifying which network owns a hop |
| -4 or -6 | Forces IPv4 or IPv6 | Comparing the two address families |
MTR compared with traceroute and ping
Ping measures only the end-to-end result: it confirms reachability, latency and loss to the destination but cannot say where along the path a problem lies. Traceroute shows the hops but sends only three probes per hop, which is too few to detect loss of a few percent. MTR joins the path view with statistical sampling, which makes it the preferred first tool for intermittent path problems.
MTR still has limits. It sees only the layer 3 hops that answer, so MPLS tunnels, switches and devices that do not decrement TTL remain invisible. For sustained monitoring, scheduled MTR runs or dedicated path monitoring platforms record a network baseline that makes deviations obvious.
Sample size also deserves attention. With 10 probes, a single lost reply already reads as 10 percent loss, so short reports exaggerate random noise. Runs of 100 to 500 cycles give loss figures that are stable enough to send to a provider, and capturing them at the time the problem actually occurs matters more than any option. A report taken in the morning says little about congestion that appears only during evening peak hours.
Finally, MTR measures the network, not the application. A clean report with low, stable latency to the destination points the investigation toward server load, DNS resolution or application behavior rather than the path, which is itself a valuable result because it ends unproductive escalations with network providers.
In everyday language
Imagine checking a long delivery route by asking every depot along the way to send a quick reply. Each reply tells you how far the parcel got and how long it took. MTR does this over and over, every second, and keeps a score for each depot.
If one depot answers slowly but parcels still arrive on time, that depot is just busy with paperwork. Only delays that carry on to the end are real problems.
Seen in the real world
A software company receives complaints from customers in one country that its web application loads slowly in the evening. A support engineer asks an affected customer to run mtr –report -c 200 –tcp -P 443 toward the application and runs the same command in reverse from the company’s servers.
The customer’s report shows 30 percent loss at the fourth hop but 0 percent at hops five to eleven, which the engineer correctly dismisses as rate limiting. From hop twelve onward, however, loss of about 6 percent and latency rising from 40 to 180 ms appear and persist to the destination. The ASN column identifies a transit provider’s congested link, and the company’s network team shifts traffic to a different upstream provider, which ends the evening slowdowns.