Jitter | ScrapeRouter

Jitter is a small random delay added to retries, request timing, or backoff so your traffic does not line up in neat bursts. In scraping, it matters because synchronized retries are a great way to hit the same rate limit again, especially when you run many workers, sessions, or accounts at once.

Examples

A basic use case is retry backoff. Without jitter, every worker sleeps for the same amount of time and comes back together.

import random
import time

def sleep_with_jitter(base_delay=2.0, spread=1.0):
    delay = base_delay + random.uniform(0, spread)
    time.sleep(delay)

for attempt in range(3):
    try:
        # make request here
        raise Exception("429 rate limited")
    except Exception:
        sleep_with_jitter(base_delay=2 ** attempt, spread=0.8)

Another case is spreading scheduled requests so a queue does not fire a few thousand jobs at the exact same second.

import random

base_interval = 60
next_run_in = base_interval + random.randint(-8, 8)
print(f"run again in {next_run_in}s")

Practical tips

Add jitter to retries, polling, and scheduled jobs: those are the places where traffic tends to synchronize.
Use more jitter when you have many workers or shared accounts: small fleets can get away with less, large fleets cannot.
Keep jitter bounded: too little does nothing, too much just makes the system slow and unpredictable.
Combine jitter with exponential backoff: backoff reduces pressure, jitter stops the thundering herd problem.
Do not treat jitter as a fix for bad rate-limit handling: if the site is telling you to slow down, lower concurrency too.
If you use a scraping API or router layer, check whether retries already include jitter: duplicating retry logic in three places is how systems get weird.

import random

def backoff_with_jitter(attempt, cap=30):
    base = min(2 ** attempt, cap)
    return base + random.uniform(0, base * 0.25)

Use cases

Multi-account scraping after a shared 429 event: without jitter, all accounts retry together and trigger the limit again.
Browser automation fleets running the same workflow: adding small random delays makes behavior less synchronized and less obviously machine-like.
Distributed crawlers pulling from one queue: jitter prevents spikes at minute boundaries, deploy restarts, or job requeues.
API scraping in production: jitter helps smooth traffic when transient failures hit many workers at once.

For ScrapeRouter users, this mostly matters when you are orchestrating your own concurrency around the API. The point is not to make requests look "human." The point is to stop your own system from behaving like a synchronized hammer.