Global MTR
MTR - traceroute combined with continuous ping - executed from probes on several continents, showing per-hop packet loss, jitter and latency so you can find where quality actually degrades.
About Global MTR
MTR answers a question plain traceroute cannot: not where the packets go, but where they start suffering. By sending many probes to every hop instead of a handful, it produces a loss percentage, an average latency and a jitter figure for each router along the path. Running it from several continents at once shows whether a quality problem is global, and therefore yours, or confined to the traffic arriving from one particular part of the world, and therefore a routing or interconnection issue on that side.
The single most important rule when reading MTR output is that loss on an intermediate hop is usually not a fault. Routers generate ICMP replies as a low-priority housekeeping task and very commonly rate-limit them, so a middle hop can report 40 percent loss while forwarding every one of your data packets perfectly. The pattern that matters is loss that begins at one hop and persists at the same or higher level through every subsequent hop including the destination: that is real loss, and the hop where it starts is where to look. Loss that appears at one hop and vanishes at the next is an artefact of ICMP rate limiting and can be ignored.
Jitter, the variation in round-trip time, is the figure to watch for anything interactive. Voice, video and gaming tolerate a surprising amount of steady latency but degrade quickly when it fluctuates, because jitter buffers have to grow to absorb the variation and that adds delay of its own. A hop where jitter climbs sharply and stays high through to the destination usually indicates congestion: a link running near capacity queues packets, and queuing delay is variable by nature. Steady latency with near-zero jitter, even if the absolute value is high, is a healthy long path.
Use the per-region comparison to place responsibility. If loss and jitter appear only in the results from one continent and start inside a transit network several hops before your infrastructure, the evidence points at that provider's path and this output is what you send them. If every probe on every continent shows the same degradation beginning at your own edge, the cause is local: an overloaded uplink, a policer, or a firewall doing more work than it can sustain. Probes come from the Globalping open network, orchestrated by our EU-hosted API, with a ten-minute cache so a repeat check costs nothing.
How to use it
- 1Enter the hostname or IP address you want to test, for example example.eu.
- 2Select Run MTR worldwide and allow more time than a traceroute: many packets are sent to every hop to make the statistics meaningful.
- 3For each region, look down the loss column for the first hop where loss appears and check whether it persists to the destination.
- 4Treat loss that appears at one hop and disappears at the next as ICMP rate limiting, not as a fault.
- 5Check the jitter column for anything interactive: rising jitter that continues to the destination usually means a congested link.
Common use cases
- -Locating the exact hop where packet loss starts, rather than knowing only that loss exists somewhere.
- -Diagnosing choppy voice or video by finding where jitter is introduced along the path.
- -Distinguishing a problem on your own uplink, which every region sees, from a single provider's congested path.
- -Building an evidence-based ticket for a transit provider, with hop, AS number, loss and jitter from an independent probe.
- -Verifying after a change that the loss or jitter you were chasing has genuinely gone from every region, not just from your office.
Frequently asked questions
- A middle hop shows high packet loss but the destination shows none. Should I worry?
- No. That router is rate-limiting the ICMP replies it generates while forwarding your traffic normally. This is the most common misreading of MTR output. Real loss propagates: if a hop genuinely drops packets, every hop after it, including the destination, reports the same loss or worse. Loss that disappears at the next hop is an artefact.
- How much jitter is too much?
- For voice and video, aim for under about 30 ms of jitter end to end; above that, jitter buffers must grow and conversation starts to feel delayed. Bulk transfers barely notice jitter at all. The absolute number matters less than where it appears: jitter that climbs at one hop and persists to the destination indicates congestion on that link.
- Why is MTR slower to complete than traceroute?
- Because it sends many packets to each hop instead of a few. That repetition is what makes per-hop loss and jitter statistically meaningful. A worldwide MTR run therefore takes noticeably longer than a traceroute, which is the price of getting quality figures rather than just a path.
- Can I use this output to open a ticket with my transit provider?
- Yes, and it is far more persuasive than a single traceroute. Include the probe's location and network, the full hop list with the AS numbers, and point at the specific hop where loss or jitter begins and continues to the destination. Because the measurement comes from an independent public probe network rather than your own machine, it is harder to dismiss as a local problem.