Retry Jitter Lab
Compare how four retry policies shape load during a modeled outage and capacity-limited recovery. Run the public Python simulator locally and inspect its assumptions before applying anything to a real service.
Experimental · v0.1.0 · Python 3.10+ · MIT
Run the public default scenario
Clone the repository and run these commands from its root with Python 3.10 or newer. The package installs from that checkout; it is not published on PyPI.
python -m pip install .
retry-jitter-lab --format json --output report.jsonThe default uses 600 clients, a 3-second outage, 120 requests per second of modeled recovery capacity, and seed 20260812. JSON includes each policy's configuration, summary and time buckets.
What this one simulation reports
In this one default scenario, no jitter finishes 192 of 600 clients and reaches 1,560 offered requests per second during recovery. The jittered policies finish 598–600 clients and spread the recovery peak to 310–510 offered requests per second. A different seed, capacity, deadline or workload can change the ordering.
| Policy | Completed | Exhausted | Recovery peak offered / s | Drain after recovery |
|---|---|---|---|---|
| No jitter | 192 / 600 | 408 | 1560 | 28.8 s |
| Full jitter | 598 / 600 | 2 | 310 | 16.2 s |
| Equal jitter | 600 / 600 | 0 | 510 | 11.7 s |
| Decorrelated jitter | 599 / 600 | 1 | 360 | 11.6 s |
Where the model stops
The model uses a hard-down interval and bucketed recovery capacity. It does not model network latency, queues, circuit breakers, retry budgets, multiple regions or real production traces. The output cannot select a production retry policy by itself; review idempotency, timeouts, dependency limits and real failure evidence before changing a client.
Continue the reliability review
Review retry behavior in a real workflow
Edilec can help frame a bounded reliability experiment around your system. Share only non-sensitive details you are permitted to disclose.