Packet Loss Monitoring: Causes, Detection, and Fixes

Some outages announce themselves with a 500 error. Packet loss is sneakier. The server is up, the site "works," but pages stall halfway, video calls stutter, API calls time out at random, and every diagnostic you run looks fine — because the packets that do arrive look perfectly healthy. Packet loss is one of the most common and most frustrating network problems precisely because it's intermittent and invisible to anything that only checks "is it up?"

This guide explains packet loss from the ground up: what it is, what causes it, how to monitor and measure it, what level is actually acceptable, and how to track down the source when it happens.

What Packet Loss Is

Networks don't send data as one continuous stream — they break it into packets, small chunks that travel independently across many hops (routers, switches, links) between you and a server. Packet loss happens when one or more of those packets never reach their destination. It's measured as a percentage: if you send 100 packets and 3 vanish, that's 3% packet loss.

What happens next depends on the protocol:

• TCP (web, APIs, most apps) detects the missing packet and retransmits it. Nothing is lost — but the retransmission adds delay, which is why TCP packet loss shows up as slowness, stalls, and timeouts rather than corruption.
• UDP itself does not retransmit, but applications can. QUIC, for example, implements reliable recovery above UDP, while real-time media often prefers concealment or selective recovery to waiting for late data.

This is the key insight: packet loss rarely takes a service fully down. It degrades it. And degradation is far harder to detect than a clean outage — see black-box vs white-box monitoring for why outside-in checks matter here.

What Causes Packet Loss

Packet loss almost always traces back to one of a handful of root causes:

• Network congestion. The most common cause. When a link or router receives more traffic than it can forward, its buffers fill and it simply drops excess packets. This is congestion working as designed — the drops are the signal telling senders to slow down.
• Faulty hardware. A failing NIC, a bad cable, a dying switch port, or an overheating router corrupts or drops packets. These tend to produce consistent low-level loss.
• Overloaded devices. A router or firewall pinned at 100% CPU can't process every packet in time, so it drops some — related to saturation, one of the four golden signals.
• Wi-Fi and wireless interference. Radio interference, distance, and contention make wireless links far lossier than wired ones.
• Misconfiguration or rate limiting. Aggressive QoS policies, traffic shaping, or firewall rules can intentionally drop packets.
• The "last mile" and routing issues. A problem at an ISP, a bad peering link, or a flapping route can drop packets on a specific segment of the path you don't control.

Notice that several of these live outside your infrastructure — which is exactly why diagnosing packet loss requires looking at the whole path, not just your own servers.

How to Monitor and Measure Packet Loss

The foundational reachability tool is ICMP echo—ping. It measures missing ICMP replies on that source-to-destination path. That can reveal path loss, but ICMP filtering or rate limiting can differ from the TCP, UDP, or QUIC traffic users actually send, so confirm with protocol-specific telemetry when possible. A single sample is a snapshot; repeated ping monitoring can expose intermittent patterns.

What good packet-loss monitoring looks like:

• Sample continuously, not once. Packet loss is bursty. A check every few minutes that sends a batch of packets reveals patterns a one-off test misses entirely.
• Track loss alongside latency and jitter. These three move together: rising latency and jitter often precede or accompany loss, and seen together they point to congestion.
• Monitor from multiple locations. A difference between regions narrows the suspect path or edge, but does not exclude an origin policy or asymmetric route that affects only one source.
• Watch for correlation with traffic. Loss that spikes with demand is congestion; loss that's constant regardless of load points to hardware.
• Alert on sustained thresholds, not single dropped packets, to avoid alert fatigue — the occasional lost packet is normal.

What Counts as Acceptable Packet Loss?

There's no universal number, but useful rules of thumb by workload:

The critical nuance: tolerance depends on codec, buffering, congestion control, RTT, burstiness, and application recovery—not only the percentage. A burst of 2% loss can be worse than evenly distributed loss, and a web transfer over a high-RTT path can also suffer badly.

How to Diagnose and Fix Packet Loss

When monitoring flags loss, work the path methodically:

1. Confirm it's real and sustained. Rule out a one-off blip with continuous sampling before chasing ghosts.
2. Narrow the path segment. Run a traceroute or MTR from affected and healthy sources. A sustained change that continues through the destination identifies a suspect segment, not necessarily one culprit: ECMP, asymmetric return paths, and ICMP control-plane policy can distort hop results.
3. Determine whose network it's on. If loss starts within your infrastructure, check device load, NICs, and cabling. If it starts at your ISP or a transit provider, escalate with the traceroute evidence.
4. Check for congestion vs hardware. Correlate with traffic levels — congestion tracks load; hardware faults don't.
5. Apply the fix: add capacity or QoS for congestion; replace faulty hardware; move off Wi-Fi or reduce interference; fix misconfigured shaping rules; or work with the upstream provider for path issues.

How Webalert Helps

Packet loss is invisible to monitoring that only asks "is it up?" — and that's the gap Webalert closes:

• Continuous outside-in checks from multiple regions that measure reachability and response time the way users experience them, catching the slow-and-degraded states packet loss causes.
• Multi-region perspective to tell "our origin is dropping packets" apart from "one network path is degraded."
• Latency and timeout tracking so the symptoms of TCP retransmission — creeping response times and intermittent timeouts — surface as alerts instead of mystery complaints.
• Alerting on sustained degradation, not single packets, so you hear about real problems without noise.

Webalert confirms whether users can actually reach and use your service across real network paths — the early warning that something on the wire is going wrong.

Summary

Packet loss is when packets fail to reach their destination, and because TCP hides it behind retransmissions, it usually shows up as slowness and timeouts rather than a clean outage. The main causes are congestion, faulty or overloaded hardware, wireless interference, and upstream routing problems — and several live outside your own network.

Monitor it with continuous ICMP sampling, always alongside latency and jitter and from multiple locations. Keep web traffic under ~1% and hold real-time traffic to a much tighter bar. When loss appears, use traceroute to find where on the path it starts, decide whether it's congestion or hardware, and fix it there. Catch it early with outside-in monitoring, and packet loss stops being the invisible problem that erodes your service quietly.

Catch the degradation users feel but tools miss

Start monitoring with Webalert ->

See features and pricing. No credit card required.