Insights
How to use tracert in CMD on Windows
Run tracert in Windows Command Prompt, read hop times and timeouts, and save results without mistaking missing replies for packet loss.
On this page
On Windows, press Windows + R, type cmd, and press EnterOpens in a new tab. In Command Prompt, run tracert followed by the hostname or Internet Protocol (IP) addressOpens in a new tab you want to check. Press Enter to see the responding hops along the route.
In short:
- Run a trace. Use
tracertwith your target's hostname or IP address. - Read each hop. Each reply time measures travel to that responding hop and back.
- Check beyond timeouts. Missing replies don't prove that application traffic was lost.
Run your first trace in Command Prompt
Follow your network's diagnostic rules and use a target you're authorized to check. This command doesn't edit network settings, so there's no configuration to restore.
1. Open Command Prompt.
Press Windows + R, type cmd, and press Enter.
2. Run the command with your target.
Use this command for Microsoft's example target. Replace the hostname with your target's hostname or IP address, not a full web address with a path.
tracert www.microsoft.com
3. Watch the results or stop the trace.
Results appear as replies arrive. You'll see numbered hop rows with reply times, responding addresses or timeout messages. Those rows show which probes got replies.
Press Ctrl+C to stop the traceOpens in a new tab. If you see timeouts, check whether later rows still reach the target.
Read the hops and reply times
The left column shows the hop number. The three middle columns show round-trip time (RTT) readings in milliseconds (ms). Each reading measures a probe's trip from your device to that responding hop and back. The final column shows the responding interface's IP address, or its hostname when a reverse Domain Name System (DNS) lookup succeeds.
Windows tracert uses Internet Control Message Protocol (ICMP) probes with increasing time to live (TTL), a hop limit. Intermediate routers reveal themselves by replying when that limit expires, while the destination can send an echo reply. Some routers don't send expiry replies, so the displayed route can be incomplete.
Each timing measures a separate round trip from your device, not just travel from the previous hop. Don't add the readings to calculate total latency. Don't subtract adjacent rows to calculate a link's delay.
Check what happens after a timeout
An asterisk means a probe didn't get the expected reply within the wait time. It doesn't by itself prove that the router dropped traffic passing through it.
Microsoft's published Windows example includes this excerpt:
13 67 ms 287 ms * ae20.r03.border101.atl02.fab.netarch.akamai.com [23.203.144.21]
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 204 ms 58 ms 51 ms a23-216-93-114.deploy.static.akamaitechnologies.com [23.216.93.114]
Hops 14 through 16 show no replies within the wait, yet the destination responds at hop 17. Those silent hops didn't prevent the trace from getting a destination reply. Read onward before blaming a silent hop, and don't treat missing diagnostic replies as confirmed loss of forwarded application traffic.
If the destination never replies, report that the trace didn't get a destination reply. The last responding router doesn't identify what caused the failure. Repeat the trace while the problem is happening and keep a working trace for context. Each run is a snapshot, not a complete diagnosis.
Use the options you need
These options change how a trace runs in Windows Command Prompt.
| CMD option | What changes | When useful |
|---|---|---|
/d | Skips intermediate name lookups | Getting numeric addresses faster |
/h <maximumhops> | Sets the hop limit | Changing how far to search |
/w <timeout> | Sets the reply wait in milliseconds | Changing how long to wait |
For a trace without intermediate address-to-name lookups, use:
tracert /d www.microsoft.com
The /d option can make results return faster. It doesn't skip the initial lookup when your target is a hostname.
The default limit is 30 hops, with a wait of 4000 milliseconds, or 4 seconds, for each reply. Lowering the hop limit can stop the trace before it reaches the destination. Shortening the wait can produce more asterisks without proving that more application traffic was lost.
Save the trace without overreading it
1. Copy the complete output.
After the trace finishes or you've stopped it, highlight its output in Windows Command Prompt. Press Enter or right-click to copy the highlighted textOpens in a new tab, then paste it into a text document.
2. Record the target and time.
Note the hostname or IP address you checked and when you ran the command. Record whether the application problem was happening during that trace.
3. Share the right copy.
Share the complete trace with support authorized to troubleshoot your network. Keep an original private copy. Before public posting, remove identifying device names and internal addresses.
A destination reply doesn't prove that a website or application worksOpens in a new tab. A firewall may allow ICMP while blocking protocols needed by a browser, file transfer or another application. Packets can also take different routes, so a trace isn't a map of every physical device or the exact path of all traffic.
tracert doesn't test encryption, tracking protection or private-network security. If you need latency or packet-loss analysis, follow up with further testing such as pathping instead of treating this trace as a complete diagnosis.