tracert and pathping in Windows: reading hop latency and packet loss

tracert maps the routers a packet passes through on the way to a destination, and pathping takes that same hop list and measures how many packets each hop and each link actually loses. Both ship with every Windows install, both run from a normal unelevated prompt, and between them they answer the question a ping cannot: not “is it reachable” but “where does it go wrong”.

The trouble is that both are read wrong more often than any other network tool on Windows. A row of asterisks in the middle of a trace gets escalated as a dropped link when it is almost always a router that simply declines to answer. A single 287 ms probe out of three gets reported as a bad hop when the other two came back in 67 ms. And pathping prints two loss columns that mean completely different things, which is the whole reason the command exists.

This page is about reading the output, not about listing the switches. The syntax tables are here for reference, but the sections that matter are the ones that explain which numbers are evidence and which are noise. If you want the same path data as PowerShell objects instead of text, that is covered in the Test-NetConnection guide.

Applies to: Windows 10 / 11 / Server 2016 / 2019 / 2022 / 2025

Quick answer

Two commands cover most investigations. The first gives you the path and the per-hop latency in a few seconds. The second gives you the per-hop packet loss, which is the number you actually need when a link is intermittent rather than down.

rem Path and per-hop latency. -d skips reverse DNS, which is the single
rem biggest cause of a trace that appears to hang on a slow hop.
rem -w 500 caps each probe at half a second instead of the 4 second default.
tracert -d -w 500 8.8.8.8

rem Same path, plus per-hop loss. -q 20 -p 100 cuts the sampling from the
rem default 12.5 minutes on a 30 hop path down to about one minute.
pathping -n -q 20 -p 100 8.8.8.8

What tracert and pathping do

Both are in %SystemRoot%\System32 on every Windows edition, client and server. Neither needs administrator rights and neither needs a feature to be enabled, so you can run everything on this page from a plain cmd or PowerShell window on a production host.

tracert sends ICMP echo requests with a deliberately short Time To Live. Every router must decrement the TTL before forwarding, so a packet sent with a TTL of 1 expires at the first router, which returns an ICMP Time Exceeded message and thereby identifies itself. The TTL is incremented and the process repeats until the destination replies or the hop limit is reached. That is the entire mechanism: the hop list is a by-product of packets dying at increasing distances.

pathping runs that same discovery first, then does something tracert never does. It pings every discovered router repeatedly over a sampling window and computes, per hop, how much of that loss belongs to the router itself and how much belongs to the link leading to it. That second number is what identifies a congested circuit.

tracert switches

pathping switches

Reading tracert output correctly

This is the sample trace from Microsoft’s own tracert reference. It is worth reading closely because it contains all three of the patterns that get misdiagnosed. Each hop line shows three probe times, then the router that answered.

Tracing route to e13678.dscb.akamaiedge.net [23.216.93.114]
over a maximum of 30 hops:

 1     1 ms     1 ms    <1 ms  mypc.mshome.net [172.26.96.1]
 2    11 ms    13 ms     6 ms  192.168.191.20
 3    20 ms    11 ms    18 ms  192.168.1.1
 4    44 ms    41 ms    35 ms  10.228.0.1
 5    32 ms    31 ms    46 ms  10.41.0.49
 6    36 ms    39 ms    30 ms  10.41.0.221
 7    35 ms    36 ms    39 ms  10.41.0.225
 8    54 ms    45 ms    50 ms  204.111.0.147
 9    50 ms    52 ms    47 ms  ae-39.a02.atlnga05.us.bb.gin.ntt.net [128.241.219.117]
10    53 ms    51 ms    61 ms  ae-5.r24.atlnga05.us.bb.gin.ntt.net [129.250.4.192]
11    64 ms    45 ms    44 ms  ae-0.a03.atlnga05.us.bb.gin.ntt.net [129.250.2.20]
12    49 ms    67 ms    46 ms  ae-0.akamai-onnet.atlnga05.us.bb.gin.ntt.net [128.241.1.122]
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]

Trace complete.

Asterisks in the middle are not a failure

Hops 14, 15 and 16 returned nothing at all, and hop 17, the destination, answered normally. Traffic clearly passed through those three routers. They just did not send the ICMP Time Exceeded message that would have identified them, either because the operator disabled it or because the router rate limits that reply. Microsoft states the case plainly: some routers silently drop packets with expired TTLs, and those packets are invisible to tracert.

One slow probe out of three is noise

Hop 13 reads 67 ms, 287 ms, then a timeout. Hop 17 reads 204 ms, 58 ms, 51 ms. Neither is a slow hop. The three probes exist precisely so you can see the spread, and the useful figure is the fastest of the three, because that is the one least affected by whatever the router was doing at that moment. Read hop 13 as 67 ms and hop 17 as 51 ms and the path looks entirely normal.

Latency at one hop only matters if it persists

The reply you time is generated by the router’s control plane, not by its forwarding hardware. Forwarding a transit packet is a fast, highly optimised operation; generating an ICMP reply pulls the packet out of that path and hands it to a general purpose CPU that treats it as low priority work. A router that is busy will answer you slowly while forwarding your real traffic at full speed.

So a single hop reading 200 ms while the hop after it reads 50 ms is not evidence of anything. Latency is only real when it appears at one hop and every subsequent hop, including the destination, stays elevated by roughly the same amount.

Practical examples

1. Get the path quickly when a site is slow

The problem: Users at a branch office report that an external service has become slow this morning. You need the routing path before anything else, and you need it now, not in three minutes.

The solution: Turn off reverse DNS and shorten the probe timeout, so a trace that would have crawled finishes in seconds.

rem Without -d, every hop triggers a PTR lookup. If the resolver is slow or the
rem zone is broken, that lookup is what you are waiting for, not the network.
rem -w 500 means a dead hop costs 1.5 seconds instead of 12.
tracert -d -w 500 outlook.office365.com

Run it a second time without -d only once you have found the interesting hop, so you get the router name for the ticket. The names are useful evidence: they usually encode the carrier and the city.

2. Stop a trace from grinding through 30 dead hops

The problem: The destination is behind a firewall that discards ICMP entirely, so the trace runs to the full 30 hop limit and prints seventeen rows of asterisks that tell you nothing.

The solution: Cap the hop count at roughly where you expect the path to end, then filter the output down to just the failures if you only care about where visibility stopped.

rem 15 hops is plenty for anything inside a corporate WAN. Beyond that you are
rem tracing the public internet and a hop cap is the only way to bound the runtime.
tracert -d -w 500 -h 15 SRV-PROD-01

rem Show only the hops that returned nothing at all. /c: matches the phrase
rem literally, so it cannot accidentally match a router name or an RTT column.
tracert -d -w 500 -h 15 SRV-PROD-01 | findstr /c:"Request timed out"

3. Keep the trace for a ticket

The problem: The carrier wants evidence, and evidence means the raw output with a timestamp, not a paraphrase in an email.

The solution: Write the trace to a file, with the date and time recorded in the same file. The block below creates its own folder, so nothing here depends on a path you already have.

rem Create the working folder first so the redirect below cannot fail.
mkdir C:\bat\test 2>nul

rem The carrier will ask when the trace was taken. Put it in the file, because
rem the file modification time is lost the moment the file is attached to a ticket.
echo Trace taken %DATE% %TIME% from %COMPUTERNAME% > C:\bat\test\trace-evidence.txt
tracert -d -w 1000 8.8.8.8 >> C:\bat\test\trace-evidence.txt

rem Read it back before attaching it.
type C:\bat\test\trace-evidence.txt

When the ticket is closed, remove the file. Nothing later in this article depends on it.

del C:\bat\test\trace-evidence.txt

4. Find intermittent loss that tracert cannot see

The problem: A site to site VPN drops sessions a few times an hour. tracert looks perfect every time you run it, because three probes per hop is far too small a sample to catch a few percent of loss.

The solution: pathping, with the sampling tuned so it finishes while you are still watching. The defaults are honest but very slow, and the arithmetic behind that is worth knowing.

rem Sampling time is numqueries x period x hops. At the defaults that is
rem 100 x 250 ms = 25 seconds per hop, so a 30 hop path takes 12.5 minutes.
rem 20 queries at 100 ms is 2 seconds per hop, or about a minute for 30 hops.
rem 20 samples still resolves loss down to roughly 5 percent, which is plenty
rem to tell a clean link from a congested one.
pathping -n -q 20 -p 100 SRV-PROD-01

rem For a link you already suspect, go the other way: cap the hops and take a
rem large, slow sample so a 1 percent problem becomes visible.
pathping -n -h 6 -q 200 -p 250 SRV-PROD-01

5. Turn a trace into objects you can threshold

The problem: You want to run a trace on a schedule and alert only when a hop is genuinely slow, which means you need numbers rather than text.

The solution: Parse the output into objects. The block below strips the ms suffix and the less-than sign that Windows prints for sub-millisecond replies, splits what is left on whitespace, and keeps the fastest of the three probes as the hop’s real latency. Hops that timed out on all three probes are dropped rather than reported as zero.

# -d is not optional here: a resolved router name adds fields to the line and
# shifts the address column, which is exactly what breaks naive parsers.
$hops = tracert -d -w 500 8.8.8.8 | ForEach-Object {
    # Remove the " ms" suffix and turn "<1" into "1" so every probe is a plain number.
    $f = ($_ -replace '\s+ms\b','' -replace '<(\d)','$1') -split '\s+' | Where-Object { $_ }

    # A hop line is: number, three probes, address. Headers and "Trace complete." are not.
    if ($f.Count -ge 5 -and $f[0] -match '^\d+$') {
        $rtt = $f[1..3] | Where-Object { $_ -match '^\d+$' } | ForEach-Object { [int]$_ }

        # No numeric probe at all means the hop is silent. Skip it rather than
        # recording a misleading 0 ms.
        if ($rtt) {
            [pscustomobject]@{
                Hop     = [int]$f[0]
                BestMs  = ($rtt | Measure-Object -Minimum).Minimum
                WorstMs = ($rtt | Measure-Object -Maximum).Maximum
                Address = $f[4]
            }
        }
    }
}

$hops | Format-Table -AutoSize

# Alert on the fastest probe, never the worst. A single slow reply is control
# plane noise, not a network problem.
$hops | Where-Object BestMs -gt 100

Run against the same path with -d, the parsed result separates the two figures that matter and makes the point about hop 13 and hop 17 immediately obvious. The table below is abbreviated to the four rows worth discussing.

Hop BestMs WorstMs Address
--- ------ ------- -------
  1      1       1 172.26.96.1
  2      6      13 192.168.191.20
 13     67     287 23.203.144.21
 17     51     204 23.216.93.114

Reading the pathping statistics table

pathping prints the hop list first, then a busy message, then the report. This is the sample from Microsoft’s reference, and the two loss columns are the entire reason to run the command.

Tracing route to contoso1 [10.54.1.196]
over a maximum of 30 hops:
  0  172.16.87.35
  1  172.16.87.218
  2  192.168.52.1
  3  192.168.80.1
  4  10.54.247.14
  5  10.54.1.196
computing statistics for 125 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  address
  0                                           172.16.87.35
                                0/ 100 =  0%   |
  1   41ms     0/ 100 =  0%     0/ 100 =  0%  172.16.87.218
                               13/ 100 = 13%   |
  2   22ms    16/ 100 = 16%     3/ 100 =  3%  192.168.52.1
                                0/ 100 =  0%   |
  3   24ms    13/ 100 = 13%     0/ 100 =  0%  192.168.80.1
                                0/ 100 =  0%   |
  4   21ms    14/ 100 = 14%     1/ 100 =  1%  10.54.247.14
                                0/ 100 =  0%   |
  5   24ms    13/ 100 = 13%     0/ 100 =  0%  10.54.1.196
Trace complete.

There are two kinds of row. Rows with an IP address in the last column are routers. Rows with a vertical bar are the links between them. That distinction is the whole point.

In this report, exactly one thing is wrong. The bar row between hop 1 and hop 2 shows 13 percent loss, so the link between 172.16.87.218 and 192.168.52.1 is dropping packets that are being forwarded along the path. The 3 percent at hop 2 and the 1 percent at hop 4 are router rows: those devices are dropping packets addressed to themselves, which does not affect their ability to forward traffic that is not addressed to them. And every “Source to Here” figure from hop 2 downward sits at 13 to 16 percent purely because it is carrying that same upstream 13 percent along with it.

Hidden gems

The first hop tells you which way the traffic left. On a multi-homed host, a VPN client, or a machine with a stale persistent route, hop 1 is the gateway your traffic actually used. If it is not the gateway you expected, stop tracing and go and read the routing table: the problem is local and no amount of hop analysis will find it.

The return path is invisible. Every RTT you see is a round trip, and the route back can differ completely from the route out. A hop that looks slow may be perfectly fine outbound and slow only on the way back, through routers that never appear in your trace. This is why a trace from both ends of a link is worth twice as much as a trace from one.

Run pathping with a hop cap when you already suspect the link. Sampling time is proportional to hop count, so -h 4 on a path where you know the problem is in the first four hops turns a twelve minute command into a two minute one, and lets you spend the saved budget on a larger -q instead. More samples over fewer hops is almost always the better trade.

Pair a trace with the interface it left from. Running ipconfig immediately before the trace, and pasting both into the ticket, prevents the most common back and forth with a carrier, which is being asked which of your circuits the test came from.

PowerShell and Linux equivalents

PowerShell has a trace of its own inside Test-NetConnection. It returns the hop list as an array of strings rather than a formatted table, which makes it easy to consume but means you lose the per-probe timings entirely.

# TraceRoute returns just the hop addresses, with * for hops that did not answer.
# There are no RTT values here, so use it for path shape, not for latency.
Test-NetConnection -ComputerName 8.8.8.8 -TraceRoute -Hops 15

# The hop list on its own, numbered, ready to paste into a ticket.
$i = 0
(Test-NetConnection 8.8.8.8 -TraceRoute).TraceRoute | ForEach-Object { $i++; "$i  $_" }

Where this matters

• Escalating to a carrier: a pathping bar row naming the two routers on either side of a congested link is actionable evidence, while a screenshot of a tracert full of asterisks gets the ticket closed as no fault found.
• VPN and SD-WAN troubleshooting: intermittent tunnel drops are almost always a few percent of loss on one underlay circuit, which only a sampled measurement will show.
• Confirming a failover actually happened: the first two or three hops change when a secondary circuit takes over, and a trace is the fastest way to see which path is live.
• Cloud and SaaS complaints: a trace shows whether traffic to a service leaves through the local breakout or is being backhauled to a central firewall, which explains most unexpected latency.
• Ruling the network out: a clean pathping across the whole path is the fastest way to move an investigation off the network team and onto the application.

Tips and limitations

• Neither tool needs administrator rights. If a trace fails on a locked down host, the cause is a firewall rule or an outbound ICMP policy, not permissions.
• Both are ICMP based, so a path where ICMP is filtered produces no useful output at all. Fall back to a TCP test for reachability and treat the trace as unavailable rather than as a negative result.
• Loose source routing, the -j and -g switches, is discarded by effectively every modern router and by every carrier. Both switches still exist and both are still documented, but they will not do anything useful on a real path.
• Equal cost multipath means consecutive probes can take different physical routes, so two traces run a minute apart can legitimately show different middle hops. That is load balancing, not instability.
• pathping gives no progress indication during the sampling window. A run that appears frozen is almost always still counting, so check the sampling arithmetic before assuming it hung.
• Anti-virus and endpoint protection products sometimes intercept raw ICMP. If a trace behaves differently on one machine than on every other machine in the same VLAN, test that theory before blaming the network.

Official documentation

• tracert | Microsoft Learn
• pathping | Microsoft Learn
• Use TRACERT to troubleshoot TCP/IP problems | Microsoft Learn

Related tools

• Network diagnostics tool: runs the connectivity checks you reach for before and after a trace.
• Port Checker: confirms the service is actually listening when a trace reaches the destination but ICMP is filtered.
• DNS Lookup Tool: resolves the router names you skipped with the DNS switch, without waiting on a slow resolver.

Related guides

• Test-NetConnection in Windows: the PowerShell path test, and the TCP check to use when ICMP is filtered.
• How to check open ports on Windows: proving a service is reachable once the path itself is confirmed.
• ipconfig command in Windows: identifying which interface and gateway a trace actually left from.
• nslookup in Windows: checking that the name resolved to the address you expected before blaming the path.
• NETSTAT command in Windows: seeing which connections are open locally once the network is ruled out.