Tracert shows the path your network traffic appears to take from your computer to a target server, one router hop at a time. On Windows, tracert sends packets with increasing Time to Live values and reports each router that answers before the destination is reached; the default maximum is 30 hops [source: Microsoft]. It is not a speed test, but it is one of the quickest ways to spot where a connection slows down, breaks, or takes a strange route.
TLDR: tracert is the Windows command, while traceroute is the common Unix, Linux, and macOS command for mapping the route to a host. Both reveal hops, response times, and possible problem points between you and a destination. For example, if a SaaS dashboard normally loads in 2 seconds but suddenly takes 12 seconds, a trace might show latency jumping from 22 ms to 185 ms at hop 8, pointing to an ISP handoff instead of your laptop. In a small support team, checking this first can cut a 30-minute guessing session down to about 5 minutes.
What the tracert command actually does
The tracert command answers a simple question: where does my traffic go before it reaches that server? When you run tracert example.com, your computer sends a series of test packets toward the destination. Each packet has a limit called TTL, short for Time to Live.
Despite the name, TTL is not really about time here. It is a hop counter. Each router that handles the packet subtracts 1. When the counter hits zero, the router drops the packet and usually sends back an ICMP “Time Exceeded” message. Tracert records that reply and shows the router as a hop.
Then tracert tries again with a higher TTL. First 1. Then 2. Then 3. Step by step, it builds a rough map of the route.
How to read tracert output
A basic Windows command looks like this:
tracert www.example.com
The output usually includes:
- Hop number: The router’s position in the route.
- Three time measurements: Round-trip times for three probes, often in milliseconds.
- Hostname or IP address: The router or destination that replied.
A healthy trace might show low numbers near you, then higher numbers as traffic travels farther away. For example, 2 ms to your home router, 12 ms to your ISP, 38 ms to a regional exchange, and 85 ms to a server across the ocean.
That pattern is normal. Distance costs time. What you are looking for is not one high number. You are looking for a pattern. A single 300 ms result in one column can be noise. A hop that rises from 20 ms to 220 ms and stays high after that is more useful. That often shows where delay begins.
Tracert vs traceroute: what is the difference?
Tracert and traceroute do the same general job. They trace a path across IP networks. The difference is mostly platform and packet style.
- tracert: Used on Windows. It commonly uses ICMP Echo Request packets.
- traceroute: Used on Linux, Unix, and macOS. Traditional versions often use UDP packets by default.
- Modern traceroute tools: Many can use ICMP, UDP, or TCP with flags and options.
This difference matters because firewalls may treat these packet types differently. A Windows tracert may fail where a Linux traceroute works. The reverse can also happen. Honestly, it feels like the tool is trolling you when three stars appear, but the website still loads fine. Most of the time, that means a router ignored the probe. It does not always mean the route is broken.
On Linux, a common command is:
traceroute example.com
On macOS, it is similar:
traceroute example.com
Some systems support ICMP mode, such as:
traceroute -I example.com
Exact flags vary by system, so check the local manual if a command fails [source: man7].
What those asterisks mean
Seeing * * * in a trace annoys almost everyone. It looks like failure. Sometimes it is. Often it is not.
An asterisk means the probe did not get a reply before the timeout. Possible reasons include:
- The router blocks ICMP replies.
- The router gives low priority to diagnostic traffic.
- A firewall filtered the packet.
- The device is too busy to answer quickly.
- There is real packet loss on that part of the route.
The key is what happens after the asterisks. If later hops respond and the destination responds, traffic is still passing through. If the trace stops and never reaches the target, you may have found a break or a filtered segment.
When tracert is useful
Tracert shines when the problem is vague. “The internet is slow” is not enough. “Our app is slow only from the Chicago office” is better. A trace can help separate local problems from upstream issues.
Use tracert when you need to check:
- Slow websites or cloud apps: Find where latency starts rising.
- Routing oddities: See if traffic takes a long path through another region.
- ISP issues: Spot delay after traffic leaves your network.
- VPN behavior: Confirm whether traffic exits from the expected location.
- Basic reachability: See how far packets get before stopping.
Picture a remote worker in Denver who cannot use a CRM system. The office users are fine. A tracert from the worker’s laptop reaches the home router in 1 ms, the ISP in 14 ms, then spikes to 240 ms at a backbone provider and stays high. That does not prove guilt in court, but it gives the support team a much better lead than “try rebooting again.”
When tracert is misleading
Tracert is useful, but it is not magic. Expect to waste time if you treat every hop as a final answer. Routers do not always handle diagnostic packets the same way they handle normal web traffic. Some routers rate-limit replies. Some hide their names. Some respond slowly to tracert while forwarding real traffic just fine.
Also, routes can be asymmetric. Your packet may go out through one path and return through another. Tracert usually shows the forward path plus replies that make it back. That means the displayed route is a strong hint, not a full contract.
Another trap is blaming the first slow-looking hop. If hop 6 shows 500 ms but hop 7 and hop 8 return to 40 ms, hop 6 is probably just slow to answer probes. If hop 6 rises to 500 ms and every hop after it also stays near 500 ms, that is more serious.
Useful tracert options on Windows
Windows includes several switches that make tracert more practical:
tracert -d example.comskips DNS lookups. This often makes results faster.tracert -h 50 example.comraises the maximum hop count to 50.tracert -w 1000 example.comsets the wait time to 1000 milliseconds per reply.tracert -4 example.comforces IPv4.tracert -6 example.comforces IPv6.
The -d option is especially handy. Reverse DNS can add delay or clutter. If you only need IP addresses and timing, skip the names. It can make a trace feel less sluggish.
Traceroute options worth knowing
On Linux and macOS, traceroute options depend on the installed version. Common examples include:
traceroute -n example.comskips hostname lookups.traceroute -m 40 example.comsets the maximum hops to 40.traceroute -I example.comuses ICMP probes on many systems.traceroute -T example.comuses TCP probes on some Linux versions.
TCP mode can be useful when ICMP and UDP are blocked. For web services, TCP probes to port 80 or 443 can sometimes resemble real traffic more closely than classic traceroute packets.
Best practice: compare from more than one place
A single trace is a snapshot. A better test uses two or three locations. Run one trace from the affected machine, one from a working machine, and one from a different network if possible. Compare where the paths split.
If only one user sees the issue, check Wi-Fi, VPN, local firewall software, and the user’s ISP. If everyone in one office sees it, check the office router, ISP circuit, DNS settings, and security gateway. If users across many regions see the same delay near the destination, the service provider or hosting network may be the issue.
The bottom line
Use tracert or traceroute as a routing clue finder. It shows hops, latency trends, timeouts, and possible choke points. Windows users reach for tracert. Linux and macOS users usually use traceroute. The names differ, and the probe types may differ, but the goal is the same: find the path and spot where things start to go wrong.
Do not treat every asterisk as disaster. Do not panic over one high hop. Watch the pattern, compare results, and pair the trace with ping, DNS checks, and real application testing. That is how a simple command becomes a practical network troubleshooting tool.