MTR: ping and traceroute together
MTR sends several packets to every router on the path, so you can see where loss and delay really start and send the evidence to whoever runs that network.
What MTR shows that traceroute does not
A traceroute sends a few packets to each router and shows the times. MTR keeps going. It sends a set of packets to every router on the path, and for each one it reports how many were lost, and the last, average, best and worst delay, with the spread. That table is the standard evidence for a slow or unreliable connection, which is why support teams ask for it.
Everything a traceroute gives you is still here: the hops in order, the network behind each one, the folded silent routers and the biggest step in delay. The packets setting runs from one to sixteen, and five is a good start. More packets make the loss figures steadier and the test slower.
Telling real loss from a router being careful
The first thing people see in an MTR is a router in the middle showing 60 percent loss, and the second is panic. Most of the time it means nothing. A router has two jobs: forwarding traffic and answering your test packets. When it is busy it protects the first job and drops the second.
| What you see | What it means |
|---|---|
| Loss at one hop, none at the hops after it | The router limits its own replies. Your traffic is not affected. |
| Loss at the last hops before the target, then the target answers fully | Those routers are filtered. It does not matter. |
| Loss that starts at a hop and carries on to the target | Real loss. The network that runs the first hop with loss is where to look. |
| Loss at the target only | The target itself drops packets, or limits its replies. Test it from another place. |
We apply this rule for you. Loss that is backed by the hops after it is shown as a warning. Loss that is not is shown quietly, with the words limited replies, instead of in red.
The report to send to your provider
Under the table there is a plain text report in the usual mtr --report layout. The first line says when the test ran, where from and to which host. Copy it into a support ticket as it is. A provider can read it at a glance, and it is hard to argue with a table that names the first hop where loss begins.
Start: 2026-11-15T07:01:00.000Z From: Los Angeles, US (HostPapa) To: github.com
HOST: probe Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.9.0.1 0.0% 5 0.3 0.3 0.3 0.4 0.3
2.|-- gw.lax.hostpapa.net 0.0% 5 0.9 0.9 0.8 1.2 0.3How to run a good test
- Start with five packetsIt is quick and enough to separate steady loss from a single dropped packet. Raise it to sixteen when the first result looks borderline.
- Use more than one placeIf the host is slow from everywhere, the problem is probably at the host. If it is slow from one place, the path to that place is the suspect.
- Try TCP when ICMP is blockedTCP on port 443 passes firewalls that drop ICMP, and it tests the path web traffic really takes.
- Read the headline firstIt names the first hop where real loss begins, or says that nothing on the path is lost.
- Run it again laterCongestion comes and goes. Two reports from different times of day make a stronger case.
The probes are volunteer machines, many of them in data centres, so they show how the internet sees the host from there and not from your house. For your own connection, run mtr on your own computer. Networks and countries are our best match and can be wrong.
Questions people ask
What does MTR stand for?
It began as Matt's traceroute and is now often read as my traceroute. It joins ping and traceroute in one tool, which is why it is the first thing network engineers reach for when a connection is unreliable.
Why does a router in the middle show 60 percent loss?
Because it limits how fast it answers test packets. If the hops after it show no loss, your traffic is passing through fine. We label that kind of loss as limited replies and keep the warning for loss that continues to the target.
How many packets should I send?
Five is a good first test. Use ten to sixteen when you need steadier figures, for example before you send a report to a provider. Each packet adds a little time to the test.
What is the standard deviation column for?
It shows how much the delay varies. A hop with a low average and a large spread answers unevenly, which can matter for calls and games even when nothing is lost.
Is this the same as running mtr on my computer?
No. It runs from the places you choose, not from your home. That is useful to see how a host looks from elsewhere. To test your own connection, run mtr or WinMTR locally and compare.
What is the difference from a plain traceroute?
A traceroute shows the path and one round of times. MTR repeats the test many times and counts lost packets, so it can tell a steady fault from a bad moment.
Use it from AI, the API or the command line
Every LookupOwl tool is also a free API and an MCP tool, with no key and no account. This one is traceroute. Please be kind to the rate limits.
curl "https://lookupowl.com/api/v1/tools/traceroute?q=github.com&preset=north-america"claude mcp add --transport http lookupowl https://lookupowl.com/mcp