Check packet loss on Windows: read ping and traceroute correctly
Packet loss can disrupt video calls, remote sessions and applications that seem to hang intermittently. Windows has built-in tools to measure ICMP responses, but interpreting the results takes care: the most striking numbers can be misleading.
Measure correctly: four packets are not enough
On Windows, ping target sends four echo requests by default. The smallest non-zero loss rate you can observe in that sample is 25%, so a real loss rate of 2% will usually go unnoticed in a four-packet run. Send more probes for a more useful snapshot:
ping -n 50 192.168.10.1 ping -n 50 8.8.8.8 ping -n 50 fileserver.firma.intern
Here, the first target represents the default gateway, the second is a public IP address that avoids name resolution, and the third is a placeholder for an internal host name. Ping tests ICMP echo replies. Filtering or rate limiting can suppress replies, so a missing ping response does not by itself prove an application fault or identify a failed network segment.
These three checks help narrow down where to look. Loss to the gateway can point to a local cable, port or Wi-Fi issue. Loss only to an external target points to missing ICMP replies beyond the local connection, but does not locate a particular segment. If a name does not resolve, investigate name resolution separately. ICMP filtering and rate limiting can affect each test, so repeat measurements and compare results.
Measure while the problem is happening
Packet loss is often intermittent and load-dependent. A test the next morning in an empty office says little about a fault reported the previous day. If possible, measure during the reported issue or repeat the checks at different times to find a pattern.
Read the output
The following output is fictional and is included only to illustrate the calculation; it is not a measurement from a real connection.
Ping statistics for 8.8.8.8:
Packets: Sent = 50, Received = 47, Lost = 3 (6% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 212ms, Average = 24ms
| Value | What it tells you |
|---|---|
| Loss % | The key measurement. With TCP, lost packets lead to retransmissions and can reduce throughput, depending on the amount and duration of loss and on the application. |
| Average | The average round-trip time in this sample. It is most useful when compared with a known-good device or an earlier baseline. |
| Maximum | The longest round-trip time observed. A single spike can show a delay, but it does not establish typical variation (jitter); assess the sequence of measurements over time for that. |
| Minimum | The shortest round-trip time observed in this sample. A high minimum can reflect a long path or sustained load, but it is not an exact physical lower bound. |
| “Destination host unreachable” | The local computer or a router reports that the destination cannot be reached. This points more toward routing, filtering or an unavailable destination; it is not automatically packet loss. |
| “Request timed out” | No reply arrived before the timeout. This can be caused by actual packet loss, but also by a firewall or other device dropping or limiting ICMP. |
A timeout to a target that blocks or rate-limits ICMP does not by itself show that application traffic is being lost. Repeat the test against a target known to reply to ICMP, and compare with checks of the application itself.
Rough guidelines, not fixed thresholds
These ranges are only a guide, not universal pass/fail limits. The effect depends on the application, protocol, duration and distribution of missing replies.
| Observed loss | Possible impact |
|---|---|
| 0% | No loss observed in this sample. If users still report a problem, investigate latency, variation, DNS or the application. |
| Under 1% | Often unremarkable for an internet test, as a rough guide. Even low loss on a local network is worth investigating across the cable, port, wireless link or adapter. |
| 1–3% | May affect voice or video; the impact depends on factors such as the codec, application and measurement path. TCP downloads may also slow down. |
| Over 3% | Can cause noticeable problems for some applications and remote sessions. The actual impact depends on the application, protocol and how long the loss lasts. |
| Over 10% | Very disruptive for many interactive applications. Narrow down the affected path instead of trying to tune around the symptom. |
A ping to the local default gateway should normally have low latency and no lost replies, but a deviation needs to be evaluated with repeat tests and the particular connection in mind. A gateway may treat ICMP differently from forwarded traffic.
Traceroute and the ICMP trap
tracert target shows the route toward a destination one hop at a time. Its output is a common source of misdiagnosis:
An asterisk at an intermediate hop is often not a fault
Routers may give ICMP replies addressed to themselves a low priority or not send them at all. If a hop shows * * * but later hops reply, that shows at least some probes travelled farther; it does not prove that every packet was forwarded or that the hop forwards traffic without loss. Even a pattern that continues to the destination does not locate the cause with certainty: ICMP filtering, rate limiting and different forward and return paths can affect the replies.
This traceroute is entirely fictional. The public addresses are from ranges reserved for documentation.
1 1 ms 1 ms 1 ms 192.168.10.1 2 8 ms 9 ms 8 ms 198.51.100.1 3 12 ms 11 ms 12 ms 198.51.100.14 4 * * * Request timed out 5 17 ms 18 ms 17 ms 203.0.113.10
Hop 4 does not reply, but hop 5 does: at least some probes travelled farther, yet that alone says nothing conclusive about ordinary traffic or the reliability of the segment. By default, tracert sends only three probes per hop, so it is not a reliable packet-loss measurement. Use it to inspect the observed route and identify places that do not reply to ICMP.
Use pathping to compare ICMP replies
pathping combines route discovery with repeated ICMP probes. Its reported loss rates describe how often routers or the destination reply to those probes; they do not directly measure how many forwarded application packets were lost on a link.
pathping -q 100 8.8.8.8
The run can take several minutes, depending on the number of hops. A loss value that appears at one router but not at later hops or the destination often points to that router limiting or prioritising its ICMP replies; it does not prove transit loss. If loss remains visible at the destination, that is evidence of missing replies on the path to it, but not proof of a particular segment. Filtering at the destination, rate limiting and asymmetric return paths are also possible. Repeat the run and compare another target or device.
Narrow down the cause systematically
- Identify the connection.Wi-Fi or Ethernet? For Wi-Fi, first check signal, band and channel. See the Windows diagnostic features for available checks.
- Test the gateway.Run
ping -n 50against the default gateway. Loss is a useful clue about a local issue, but consider ICMP handling and repeat the test. - Test an external IP address.This avoids name resolution. Loss seen only here points to missing ICMP replies beyond the local connection, but does not locate a particular segment; the destination may also filter or limit ICMP.
- Separate name resolution.If IP addresses reply but names do not resolve, investigate name resolution. If a name resolves but ping then fails, investigate those results separately. See how to read ipconfig /all.
- Inspect the route.Use
tracertto see the route andpathpingto compare ICMP replies from routers and the destination. - Compare a second device.Repeat the same checks on a working computer on the same network. The comparison can help distinguish a device, port or network issue.
Manual measurements take time to repeat on multiple devices. admin-tools runs ping with configurable targets, traceroute, routing-table and DNS checks in one pass, and reports packet loss plus minimum, average and maximum reply time for each target. These remain snapshots and do not replace checks of filtering rules or application traffic. The same batch file can be shared with several users for comparison. See the Windows diagnostic features and the static Windows sample report with fictional data.