How to run a traceroute (and read the results)

Q: What can a traceroute tell you?

It’s great for seeing where latency is introduced and whether the problem is inside your own network, at your ISP, or further out. It does not measure your bandwidth (download/upload speed), and the per-hop times can look alarming even on a healthy connection because intermediate routers often answer probes slowly while still forwarding real traffic quickly. For a clean read on your connection’s responsiveness and stability, pair it with our latency test, which measures real round-trip time and jitter to our node.

Quick answer

A traceroute shows the path your data takes across the internet to reach a server — every router (“hop”) it passes through, and how long each step takes. It’s the go-to tool for finding where a slow or broken connection is failing. The key thing to know up front: a traceroute has to run from your own device, because the whole point is to map the path from you to the destination.

Why this runs on your computer, not in your browser

We can’t run your traceroute for you from this page, and neither can any website — honestly. A traceroute needs low-level network access (raw packets with stepped “time-to-live” values) that browsers don’t allow, for good security reasons. And even a server-side trace would map the path from that server, not from your connection — which is the opposite of what you want. So the real, accurate way is to run one command on your own machine. It takes about ten seconds.

How to run a traceroute on Windows

Open Command Prompt (press Windows key + R, type cmd, Enter) and run:

tracert example.com

Replace example.com with the site or IP you want to trace. Windows calls it tracert (not traceroute). It shows three timing samples per hop.

How to run a traceroute on Mac or Linux

Open Terminal and run:

traceroute example.com

On most Linux systems this is built in; if not, install it (for example sudo apt install traceroute on Debian/Ubuntu). On macOS it’s included by default. There is also a friendlier live version, mtr, that combines traceroute and ping and updates continuously.

How do I read traceroute results?

Each numbered line is one hop — one router along the way — with its address and the round-trip time to reach it. Reading from top to bottom: the first hop is usually your own router, the next few are your ISP’s network, and later hops cross the wider internet to the destination. A few things to look for:

A steady rise in times as hops get farther away is normal — more distance means more delay.
A sudden jump that stays high from one hop onward points to congestion or a slow link at that point in the path.
Asterisks (* * *) mean a hop didn’t reply. That’s often harmless — many routers deprioritise or block the probe traffic — and doesn’t necessarily mean a problem unless the trace stops completely there.
The trace ending before it reaches the destination can indicate a firewall along the way, or a genuine break in the path.

What can a traceroute tell you?

It’s great for seeing where latency is introduced and whether the problem is inside your own network, at your ISP, or further out. It does not measure your bandwidth (download/upload speed), and the per-hop times can look alarming even on a healthy connection because intermediate routers often answer probes slowly while still forwarding real traffic quickly. For a clean read on your connection’s responsiveness and stability, pair it with our latency test, which measures real round-trip time and jitter to our node.

Common issues

If tracert or traceroute isn’t recognised, the tool may not be installed (Linux) or you may have a typo — remember Windows uses tracert. If every hop after the first shows timeouts, your router or ISP may be blocking the probe protocol; trying the same trace to a different destination, or using tracert -d (skip name lookups, faster), can help. A trace that’s slow to start is usually just waiting on reverse-DNS lookups for each hop.