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 (video, voice, gaming, DNS) usually doesn't retransmit. The packet is simply gone, which is why packet loss on a call sounds like choppy audio or a frozen frame.
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 tool is ICMP echo — ping. By sending a sequence of echo requests and counting how many replies come back, you get a direct packet-loss percentage. A single ping is a snapshot; continuous ping monitoring over time is what actually catches intermittent loss.
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. Loss seen from one region but not another localizes the problem to a network segment or CDN edge, not your origin.
- 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:
| Packet loss | Impact |
|---|---|
| 0% | Ideal — but rarely sustained on real internet paths |
| < 1% | Generally acceptable for web/API traffic; TCP retransmits absorb it |
| 1–2.5% | Noticeable for real-time apps (voice, video, gaming); marginal |
| 2.5–5% | Degraded — calls choppy, pages slow, timeouts climb |
| > 5% | Serious problem — likely user-visible failures and stalls |
The critical nuance: real-time UDP traffic is far less tolerant than TCP web traffic. A 2% loss your website shrugs off can make a video call unusable, because there's no retransmission to paper over the gap. Set your thresholds based on what's actually running over the link.
How to Diagnose and Fix Packet Loss
When monitoring flags loss, work the path methodically:
- Confirm it's real and sustained. Rule out a one-off blip with continuous sampling before chasing ghosts.
- Find where on the path it happens. This is the crucial step: run a traceroute or MTR to see hop-by-hop where packets start disappearing. Loss that begins at a specific hop and continues localizes the culprit. (Beware: some routers deprioritize ICMP to themselves, so loss at a single middle hop that doesn't carry forward is often a false alarm.)
- 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.
- Check for congestion vs hardware. Correlate with traffic levels — congestion tracks load; hardware faults don't.
- 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.