Online MTR Test — Continuous Hop-by-Hop Analysis

MTR combines traceroute and ping into one continuous measurement. Rather than mapping the path once, it probes every hop repeatedly and reports loss and latency statistics for each — which is the only reliable way to catch a fault that appears intermittently.

This is the tool to reach for when your connection is fine most of the time and unusable for thirty seconds every hour.

What each column means

• Loss% — packets to that hop that went unanswered.
• Snt — probes sent, so you can judge whether the sample is large enough to trust.
• Last / Avg / Best / Wrst — most recent, mean, minimum and maximum round-trip time to that hop.
• StDev — how much the timings vary. High deviation with low average means jitter, which breaks calls even when the average looks healthy.

The three patterns worth knowing

Loss that starts at one hop and continues to the destination is real. Something at or just before that hop is dropping traffic, and every hop after it inherits the damage.

Loss at a single hop that clears afterwards is almost always harmless. That router is rate-limiting its own ICMP replies while forwarding your actual traffic perfectly. This is the single most common misreading of MTR output, and it sends a lot of people chasing faults that do not exist.

Rising latency with no loss usually means congestion or a queue building somewhere — bandwidth is saturated but packets still get through, just late.

Reverse path testing

Network problems are frequently asymmetric: the route from you to a server can be healthy while the return path is faulty. Because a normal MTR only measures the outbound direction, that kind of fault stays invisible. This tool can also run MTR from our server back toward your address, exposing the return path that standard tools never show you.