Your average latency looks fine — 30 ms, green across the board. Yet calls break up, video freezes, and the game rubber-bands. The culprit usually isn't latency at all. It's jitter: the variation in latency from packet to packet. A connection with low average latency but high jitter feels worse than a slower-but-steady one, and most dashboards barely show it.
This guide explains what jitter is, why it wrecks real-time applications, how it's measured, what counts as acceptable, what causes it, and how to monitor it before users complain.
What Jitter Actually Is
Latency is how long one packet takes to travel. Jitter is how much that travel time varies between consecutive packets.
Imagine packets sent exactly 20 ms apart. On a perfect network they'd arrive 20 ms apart. In reality they arrive at uneven intervals — 18 ms, then 25 ms, then 19 ms, then 31 ms. That inconsistency in arrival timing is jitter, usually reported as the average deviation between expected and actual inter-packet arrival times (per RFC 3550, the RTP standard).
Sent: |--20ms--|--20ms--|--20ms--|--20ms--| (steady)
Arrived: |--18ms--|---25ms---|-19ms-|----31ms----| (jittery)
^variation = jitter
The key insight: jitter is independent of average latency. You can have low latency and terrible jitter, which is exactly why a connection can look healthy on average yet feel broken.
Why Jitter Breaks Real-Time Applications
For bulk transfers (downloads, web pages, APIs), jitter barely matters — TCP reassembles everything in order. Jitter hurts real-time, time-sensitive traffic:
- VoIP / phone calls — audio is sampled at fixed intervals. Packets arriving unevenly cause choppy, robotic, or dropped audio.
- Video conferencing — frames freeze, pixelate, or desync from audio.
- Online gaming — uneven updates cause lag spikes and "rubber-banding."
- Live streaming — buffering and quality drops.
These applications use a jitter buffer — a small holding area that deliberately delays playback to smooth out uneven arrivals. A jitter buffer can absorb some variation, but it's a trade-off: a bigger buffer hides more jitter at the cost of more delay. When jitter exceeds the buffer, packets arrive "too late to use" and are discarded — which shows up to the user as the same symptoms as packet loss.
Acceptable Jitter: Rough Thresholds
Targets depend on the application, but as a working guide for real-time traffic:
| Jitter | Quality for VoIP/Video |
|---|---|
| < 15 ms | Excellent — imperceptible |
| 15–30 ms | Acceptable — generally fine |
| 30–50 ms | Noticeable — occasional glitches |
| > 50 ms | Poor — audible/visible disruption |
Common rules of thumb: keep jitter under 30 ms for VoIP, packet loss under 1%, and one-way latency under 150 ms. For bulk/non-real-time traffic, jitter is largely irrelevant — judge it against the workload, not a universal number.
What Causes Jitter
Jitter comes from anything that makes packets wait inconsistently on their journey:
- Network congestion — the biggest cause. When links fill up, queues form and drain unevenly, so packets wait varying amounts of time.
- Inadequate or missing QoS — without Quality of Service prioritization, latency-sensitive voice/video packets compete equally with bulk downloads.
- Route changes / load balancing — packets taking different paths arrive with different delays.
- Overloaded or underpowered hardware — routers, switches, or firewalls that can't keep up buffer erratically.
- Wi-Fi and wireless — interference, contention, and retransmissions make wireless inherently jittery versus wired.
- Bufferbloat — oversized buffers that hold packets too long under load, adding variable delay.
How to Measure Jitter
Two practical approaches:
Quick manual check with ping
A burst of pings reveals variation in round-trip times. Look at the spread (and the mdev/standard-deviation figure on Linux):
ping -c 20 example.com
# rtt min/avg/max/mdev = 18.2/24.6/41.9/6.3 ms
# ^^^ mdev ≈ jitter indicator
A large gap between min and max, and a high mdev, both point to jitter. For a richer view of the path, mtr example.com shows per-hop latency and loss so you can see where the variation is introduced.
Continuous measurement
A one-off ping only captures this moment. Jitter is bursty and tied to congestion patterns that come and go through the day, so the reliable way to catch it is continuous measurement that records inter-packet variation over time and alerts when it crosses your threshold.
Jitter vs Latency vs Packet Loss
These three travel together but mean different things — and fixing one doesn't fix the others:
| Metric | What it measures | Hurts most |
|---|---|---|
| Latency | Absolute delay per packet | Responsiveness, TTFB |
| Jitter | Variation in that delay | Real-time audio/video/gaming |
| Packet loss | Packets that never arrive | Everything — retransmits, gaps |
High jitter often causes effective packet loss (late packets get discarded by the jitter buffer), and congestion tends to spike all three at once. That's why you monitor them together rather than in isolation — and why looking only at average latency (or worse, a single latency number instead of percentiles) hides the real user experience.
Reducing Jitter
If monitoring flags high jitter, the usual levers are:
- Implement QoS to prioritize real-time traffic over bulk transfers.
- Relieve congestion — upgrade saturated links, or shape/limit heavy background traffic.
- Prefer wired over Wi-Fi for fixed VoIP/video endpoints.
- Tune the jitter buffer — size it to your measured jitter (bigger absorbs more variation but adds delay).
- Fix bufferbloat with modern queue management (e.g. fq_codel).
- Check hardware — replace or offload overloaded routers/firewalls.
How Webalert Helps
Jitter is invisible until you measure variation over time — which is exactly what continuous monitoring does:
- Latency & packet-loss tracking via ping monitoring so you see the variation, not just an average that looks fine.
- Multi-region checks to tell whether jitter is global or specific to one network path — see why location matters.
- Threshold alerts that fire when latency variation or loss crosses the limits your real-time services can tolerate.
- Historical trends so you can correlate jitter spikes with congestion windows, deploys, or routing changes.
Pair this with latency percentiles to capture the tail experience that averages hide.
Summary
Jitter is the variation in latency between packets — and for VoIP, video, and gaming it matters more than average latency does. Aim for under ~30 ms for real-time traffic, watch it alongside latency and packet loss (they move together), and remember that a connection can show a healthy average while jittering badly underneath.
Because jitter is bursty and congestion-driven, a single ping won't reveal it. Measure variation continuously, alert on your thresholds, and you'll catch the "calls keep breaking up but everything looks green" problem before your users report it.