Jitter

What jitter is

Jitter describes irregular timing. The word is used in two ways that engineers meet regularly, and they are worth keeping apart:

• Network jitter is unwanted variation in latency. If packets arrive after 20 ms, 22 ms, 61 ms and 19 ms, the average looks fine but the spread disrupts real-time traffic.
• Jitter in backoff and scheduling is wanted randomness. You add it on purpose so that retries, cron jobs or cache refreshes from many clients do not all happen at exactly the same time.

Both share the same idea: timing that varies around an expected value. One is a symptom to measure, the other a technique to apply.

Jitter in networks

In networking, jitter is formally called packet delay variation. IETF RFC 3393 defines IP packet delay variation as the difference in one-way delay between selected packets, and RTP (RFC 3550) specifies a smoothed interarrival jitter estimate that receivers report to senders. Typical causes are queueing in congested routers and switches, route changes, Wi-Fi retransmissions, competing bulk transfers and CPU contention on virtualized hosts.

Jitter matters most for real-time applications. Voice and video receivers use a jitter buffer that holds packets briefly to play them back evenly; when jitter exceeds the buffer, packets arrive too late and audio breaks up. For voice, a figure of around 30 ms is a widely cited guideline, but vendors and codecs differ. For request/response APIs, high jitter shows up as a wide gap between median and tail percentiles.

How to measure jitter

Method	What it shows
Mean absolute difference of consecutive delays	Packet-to-packet variation, close to the RTP definition
Standard deviation of latency	Overall spread around the mean
Gap between p50 and p99 latency	How much worse the tail is than the typical case
Tools such as ping, mtr or iperf3 in UDP mode	Ad-hoc measurement along a path

Measure continuously from fixed vantage points rather than once during an incident, so you know what normal variation looks like.

Jitter in retries: exponential backoff

When a dependency fails, clients retry. With plain exponential backoff, every client that failed at the same moment waits 1 s, 2 s, 4 s and so on in lockstep, and each retry wave hits the recovering service at once. Adding jitter spreads those waves out. Marc Brooker's widely referenced AWS Architecture Blog article "Exponential Backoff And Jitter" compares variants:

• Full jitter: sleep = random(0, min(cap, base * 2^attempt))
• Equal jitter: half the backoff fixed, half random.
• Decorrelated jitter: sleep = min(cap, random(base, previous_sleep * 3))

In his simulations, full and decorrelated jitter reduced total work and completion time markedly compared with no jitter. A simple implementation:

import random, time

def retry(call, attempts=5, base=0.1, cap=5.0):
    for attempt in range(attempts):
        try:
            return call()
        except TransientError:
            if attempt == attempts - 1:
                raise
            time.sleep(random.uniform(0, min(cap, base * 2 ** attempt)))

Combine this with a retry budget and a circuit breaker, so retries stop entirely when a dependency is clearly down, and honor server hints such as HTTP Retry-After from rate limiting.

Jitter in schedules

The same thundering-herd problem appears with schedules. If thousands of hosts run a cron job at minute 0, or every cache entry expires exactly one hour after a deploy, load spikes at that moment. Common remedies are a random splay before the job starts (systemd timers offer RandomizedDelaySec), randomized cache TTLs such as 60 minutes plus or minus 10%, and spreading polling clients across the interval. Prometheus applies the same idea to scraping by offsetting each target within the scrape interval. Jitter here does not change how much work is done, only when it happens, which is often enough to flatten a dangerous peak into a manageable plateau.

Common mistakes

Teams often monitor only average latency and miss jitter completely, retry without any randomness, or seed every client's random generator identically so the "jitter" is the same everywhere. Another mistake is treating all jitter as network jitter when the real cause is garbage collection pauses or CPU throttling on the host.

How Obseria helps

Obseria keeps full latency distributions from traces and metrics, so the spread between p50 and p99 is visible over time instead of hidden in averages. Network monitoring adds visibility into the network path, and synthetic checks from 50+ locations provide a stable outside-in reference for how response times vary by region.