A traceroute test is not busywork before a network ticket — it is the one piece of evidence that tells anyone, including you, whether a connection problem is happening on your side, in the middle of the internet, or genuinely at the destination.
What it actually measures
MTR (or WinMTR on Windows) sends a continuous stream of packets toward a destination and reports, hop by hop, how long each intermediate router took to respond and what percentage of packets it lost — building a picture of the entire path rather than just a single round-trip time. Because it runs continuously rather than once, it also catches intermittent loss a single ping would miss entirely.
Reading where a problem sits
| Loss or spikes appear at | Points to |
|---|---|
| Hop 1 or 2 (your own router) | Your local network — a ticket will be closed as external |
| The first few hops after your router (your ISP) | Your ISP's own network — also outside what a ticket about the node can fix |
| Middle hops, transit networks | Internet backbone routing, usually resolves itself and is outside anyone's direct control |
| The final hop, at the destination | Worth reporting — this is the one pattern that points at the node's own network |
What to do
- Run WinMTR (Windows) or mtr (Linux/macOS) toward the node's address
At least 100 packets sent — a short run can miss the intermittent loss that is often the actual complaint.
- Let it run during the actual problem, not before or after it
A clean result taken when the connection feels fine proves nothing about the moment it did not.
- Attach the full table, not a cropped screenshot
Support needs every hop's numbers to read the pattern, not just the summary line.