Random variance added to a fixed interval (retries, polling, scheduled jobs) to prevent thundering-herd synchronization.
Jitter is randomness deliberately added to a fixed schedule. The classic example is exponential-backoff retry: instead of retrying at exactly 1s, 2s, 4s, 8s, you retry at random intervals within those windows. The reason is thundering herd: if 10,000 clients all retry at exactly t+1s after a downstream blip, the downstream gets a synchronized spike that's worse than the original problem. Jitter spreads the retries out, which both reduces peak load and avoids retry-induced cascading failures.
Most cascading failures in distributed systems are not load problems, they're synchronization problems: a small downstream hiccup causes thousands of clients to retry on identical schedules, which DDoS-es the recovering downstream and makes the whole system worse. Adding jitter to retry, polling, scheduled-job, and cache-refresh schedules is one of the cheapest reliability investments an SRE can make.
See the part of the platform that handles jitter in production.