There's a Windows command that shows exactly what's slowing your internet down

Diagnosing a slow internet involves a lot of guesswork. You might blame your router for slow evening internet, reconfigure your DNS settings to see if your ISP's DNS is causing the issue, or run the ping command to confirm that yes, something is definitely slow. But ping only tells you the round-trip time to the final destination. It doesn't tell you where the slowdown is actually happening.

That's where the tracert command comes in. Short for trace route, it maps every router your data passes through on its way to a server and measures the response time at each stop. Instead of just confirming that your connection is slow, tracert shows you exactly which hop along the path is causing the delay, whether the problem is with your router settings quietly hurting your internet speed, your ISP's infrastructure, or a congested route on the wider internet.

How traceroute works

Tracert maps every hop between you and the server

When you type tracert google.com into Windows Terminal or Command Prompt, the command sends packets with incrementally increasing TTL (Time To Live) values, forcing each router along the path to identify itself. This way, tracert discovers each router in order and measures how long it takes to reach each one.

The output might seem tricky to make sense of, but it's rather simple once you know what to look for. The first column is the hop number, the next three show the round-trip time (RTT) for three separate probes, and the last column shows the router's IP address or hostname. Three probes per hop might seem redundant, but it's how you tell a real problem from a one-off glitch.

Here's what a healthy trace to Google.com looks like from my connection:

This is a clean, healthy trace. Hop 1 is my local router at 1-2 ms. Hops 2 and 3 are my ISP's infrastructure, still under 6 ms. The RTT bumps up at hop 4 as traffic enters the wider internet, then stays consistent through Google's network to the destination. No sudden spikes, no timeouts.

An RTT spike pinpoints the bottleneck

Watch where the latency jumps and stays high

A trace to a nearby server might seem uneventful. But I first reached for tracert when a Japanese news site I occasionally read felt unusably slow. Pages took forever to load, and I assumed something was wrong with my connection or the site itself. So I ran tracert yahoo.co.jp to find out.

The first three hops stayed under 4 ms, so my local network and ISP were fine. But look at hop 4: the RTT jumped to 66 ms as traffic left my ISP. At hop 5, it climbed to 77 ms through an Equinix exchange point. Then at hop 6, the RTT nearly doubled to 132 ms as the connection hit IIJ.Net routers in Tokyo, likely crossing an undersea cable from India to Japan. The remaining hops stayed in the 133-144 ms range, and the destination came in at 160-205 ms.

The key pattern to look for: when the RTT spikes at a specific hop and stays elevated for all subsequent hops, the slowdown starts at that hop. Everything after inherits the delay. In my case, the jump at hop 6 wasn't a broken router or congested link. It was simply the physical distance between India and Japan. Tracert showed me that my connection wasn't broken; the site was just far away, and no amount of troubleshooting on my end would change that.

That's the real value. If the spike had appeared at hop 2 or 3, I'd know the problem was on my ISP's end. If it appeared at hop 1, I'd be looking at my own router. Tracert doesn't just show you that something is slow; it tells you whose problem it is.

The three probes per hop confirm whether a spike is real. If all three RTTs are consistently high compared to the previous hop, it's a genuine increase in latency. If only one is high while the others are normal, it's likely a transient blip.

Not every anomaly means something is broken

Timeouts and spikes can be perfectly normal

In the same yahoo.co.jp trace, hop 10 showed asterisks across all three probes with a "Request timed out" message. That looks alarming, but the trace completed just fine at hop 11, reaching the destination. The router at hop 10 simply doesn't respond to tracert probes. Many routers are configured this way for security reasons or to reduce processing overhead. They still forward your actual traffic; they just don't reply to diagnostic packets.

Tracert also sends probes over a default maximum of 30 hops. If the destination isn't reached within that limit, you'll see "Request timed out" for every remaining hop, which often just means a few routers along the path are blocking probes while still passing traffic normally. Similarly, one high probe out of three at a given hop is usually transient noise, not something worth investigating.

The anomalies worth paying attention to are the ones that don't have a logical explanation. A spike that corresponds to physical distance or a single timed-out hop in an otherwise clean trace is normal. A spike from 20 ms to 200 ms between two routers in the same city, or consistently elevated RTTs starting at a specific ISP hop, is when you've found something actionable.

Stop guessing what's wrong with your network

Tracert won't fix your slow internet, but it takes the guesswork out of figuring out where the problem actually is. When I've had streaming issues caused by poor network routing, running a quick trace has helped me narrow things down before I started changing settings or calling my ISP.

That said, tracert has its limits. It shows the forward path from your machine, not necessarily the return path, and some networks treat tracert probes differently from regular traffic. It also won't catch packet loss or jitter that don't show up in RTT measurements. For those, pathping on Windows goes a step further by measuring packet loss at each hop over a longer period. Still, as a first step in diagnosing a sluggish connection, tracert gives you more actionable information in seconds than most people get from hours of trial and error.