How to test for packet loss, and what counts as too much

Packet loss is the network problem that never announces itself. There is no error message, no red icon, nothing in the status bar. Instead you get a video call where people freeze mid sentence, a game that rubber bands, a download that crawls despite a fast connection, and a speed test that comes back looking perfectly normal.

That last part is why so many people go in circles. A standard speed test measures throughput over a few seconds on a handful of parallel connections. It is genuinely bad at exposing intermittent loss. You can lose two percent of packets and still post a respectable number, while every real time application on your network quietly falls apart.

So let us do it properly.

What packet loss actually is

Your data travels as discrete packets. Some of them do not arrive. That is it.

What makes it interesting is how differently applications react. A file download barely notices: TCP detects the gap, retransmits, and you lose a little speed. A voice or video call has no time to retransmit anything, so the missing audio is simply gone and you hear a gap or a robotic stutter. A game predicts what should have happened, then corrects when the real data shows up, which is what rubber banding is.

The same one percent loss is invisible on a download, annoying on a call, and unplayable in a shooter. This is why "my internet is fine, it is just this app" is such a common and misleading statement.

How much is too much?

Loss over a sustained test	What it means
0%	Ideal, and completely normal on a healthy wired connection.
Under 1%	Generally fine. Web and streaming will not notice. Competitive gaming might.
1% to 2.5%	Calls start to degrade. Audio clips, video artifacts, occasional freezes.
2.5% to 5%	Clearly broken for anything real time. Worth escalating.
Over 5%	Something is genuinely wrong. Hardware, wiring, interference or a saturated link.

Two caveats. First, a handful of dropped packets in a 10 packet test means nothing. You need enough samples for the percentage to be real, which in practice means at least a few hundred. Second, where the loss happens matters as much as how much. Loss on your own Wi-Fi is your problem to fix. Loss six hops into a transit provider's network is not.

How to test for packet loss

The measurement itself is simple. Send a lot of pings to a stable target and read the loss percentage in the summary. The part people get wrong is the duration.

1. Pick a target that will not lie to you

   Use 1.1.1.1 or 8.8.8.8. They are well connected and they answer ICMP reliably. Do not test against a random website: many of them deprioritise or block ping entirely, and you will measure their policy rather than your network.

2. Run long, not short

   Set the count to 0 in the Ping tool and let it run continuously for at least five minutes. Intermittent loss is intermittent. A 10 packet test that comes back clean proves nothing at all, and a 10 packet test that drops one packet tells you 10 percent loss, which is nonsense.

3. Test the gateway too

   Run the same test against your own router. Loss between your device and your router is almost always Wi-Fi, and it rules the entire internet out in one step.

4. Repeat on Ethernet if you can

   If the loss disappears on a cable, you have found it. Wi-Fi is the single most common source of loss in a home, by a wide margin.

5. Test at the time it goes wrong

   Loss that only shows up at 8pm is a congestion signature. Loss that appears when someone starts a big upload is a buffer problem. Loss that tracks the weather is a physical line problem. The timing is evidence.

# Continuous ping, run it for five minutes and read the summary
https://netdebug.app/open/ping?target=1.1.1.1&count=0

# Same test against your own router
https://netdebug.app/open/ping?target=192.168.1.1&count=0

Finding where the loss happens

Once you know loss exists, you walk outward until it appears. Each test adds one segment of the path.

Target	Clean result means	Loss here means
Your router (192.168.x.1)	Local link is healthy	Wi-Fi interference, weak signal, bad cable, failing port
Your ISP's first hop	The line into your home is fine	Modem, line quality, the drop to the street
1.1.1.1 or 8.8.8.8	General internet is fine	Congestion or a fault upstream
The specific server you care about	That service is reachable	A problem on one route or at that provider only

If the router is clean and everything past it drops, the problem is outside your home and you have something concrete to report. If the router itself drops packets, no amount of shouting at your ISP will help.

The traceroute trap that fools everyone

This one is responsible for an enormous number of wrong conclusions, so it deserves its own section.

Run a traceroute and you will often see a middle hop showing 40 percent loss or a row of asterisks, while the final destination shows zero loss. It looks alarming. It is almost always meaningless.

Routers deprioritise ICMP responses aimed at themselves. Forwarding traffic is their job, replying to traceroute probes is a courtesy, and under load they simply stop replying. The packets still pass through perfectly. So a hop that "loses" probes while every hop after it is clean is not losing your traffic, it is just rate limiting the replies.

The rule: only loss that continues all the way to the destination is real. If hop 7 shows loss and hops 8 through 14 are clean, ignore hop 7. If loss begins at hop 7 and every hop after it shows the same loss or worse, you have found where it starts.

The same logic applies to latency. A middle hop with a 300ms reply time while later hops answer in 20ms is a busy control plane, not a slow path.

What actually causes it

Wi-Fi, most of the time

Interference from neighbouring networks, microwaves, Bluetooth devices and baby monitors. Distance and walls. Too many clients on one band. An old 2.4GHz only device dragging down a whole network. Test on a cable once and you will know within a minute whether to keep digging here.

A saturated uplink

Home connections have far less upload than download. One backup, one cloud sync or one video upload can fill it completely, and when the buffer overflows, packets get dropped. The signature is obvious once you know it: loss and latency both spike when someone starts an upload, then recover. This is bufferbloat, and modern queue management on the router genuinely fixes it.

Physical line problems

Corroded connectors, water in a junction box, a splitter that should not be there, a chewed cable. These often correlate with weather or time of day. Cable and DSL modems keep signal quality statistics in their admin pages, and if those numbers are out of range, that is your answer.

Failing hardware

Routers and switches die slowly. An overheating router that works fine for two hours and then starts dropping traffic is a very common pattern. So is a cheap unmanaged switch with a failing port. Swap components out one at a time.

Congestion upstream

If the loss is beyond your ISP's edge and only during peak hours, it is capacity. You cannot fix it. You can document it: run the same test every hour for a couple of days, then show the pattern. A chart of loss over time carries far more weight with support than "it feels slow in the evenings."

Building a repeatable test

Loss that comes and goes is best caught by testing the same way at different times, then comparing. Chain a continuous ping, a traceroute and a speed and latency baseline into one automation, run it whenever the problem shows up, and let the history build.

After a week you will have something a support agent cannot dismiss: identical tests, timestamped, showing exactly when the network degrades and exactly how far out the degradation starts.

The short version

Ping a reliable target continuously for at least five minutes, not ten packets. Anything under one percent is usually fine, anything over two and a half is not. Test your router first to separate your Wi-Fi from the internet. And when you read a traceroute, ignore loss at middle hops unless it carries through to the destination.