How to Read an MTR Report Without Mistaking Every Hop for Packet Loss

MTR combines repeated probes with a view of the route toward a destination. Its report can be useful when a VPS connection feels unreliable, but a red percentage beside an intermediate router is not enough to identify a fault. Routers can treat replies generated for diagnostic traffic differently from the traffic they forward. Begin with the destination and the user-visible symptom.

Capture a bounded, relevant sample

Run a limited report toward your own VPS or another destination you are authorized to test. Record the source network, destination address, start time with timezone, duration, and probe mode. A few minutes collected during the actual problem is more useful than a screenshot taken hours after everything recovered. Avoid continuous high-rate probing.

If the service uses TCP, a supported TCP probe mode may provide a useful comparison with ICMP probes, although it still does not reproduce an entire application request. Document the chosen destination port. Keep a normal application check running alongside the report so the network sample has a connection to real behavior.

Compare intermediate rows with the destination

Suppose hop six reports missing replies while every later hop, including the destination, responds consistently. That pattern is compatible with hop six limiting its own diagnostic replies. It does not show that the same proportion of forwarded application packets was discarded there. Do not identify that router as the cause solely from its loss column.

If loss appears at one point and continues through subsequent responding hops to the destination, the pattern deserves investigation. Even then, route asymmetry and reply handling limit what a single report proves. The destination's own firewall can also suppress probes while the application remains accessible.

Read latency as a distribution

Compare average and worst observed times across repeated samples, then relate them to the application's delay. A single high reply time does not describe the typical path. If the destination shows consistent latency while one intermediate row is erratic, that row may again reflect local response priority rather than forwarding performance.

For a voice service with intermittent dropouts, record the dropout times and compare them with destination loss and jitter in the same interval. For a slow dashboard, also measure HTTP response time because the database or application may dominate the delay. The same MTR report can mean different things depending on the symptom.

Send evidence that can be compared

Provide text output rather than a cropped image when possible. Include tests from another network and the opposite direction if you control both endpoints. Routes can be asymmetric, so one direction is not a substitute for the other. Remove sensitive internal labels before public sharing, but retain enough addressing information in a private support ticket to identify the path.

Check the official MTR project for supported options. Our latency planning article provides regional context, and the LayerOne documentation helps locate server details for a support report.