Integration & B2B
Retry & backoff simulator
Model a retry policy against the caller's deadline, and see how many attempts happen after everyone has given up — plus what nested retries do to the service at the bottom.
Local files can contain entered information. Raw CSV preserves values and may be interpreted as formulas by spreadsheet software. Spreadsheet-safe CSV prefixes formula-like and leading-zero values with an apostrophe, changing those cells to text. JSON reports remain unchanged.
Compare your assumptions
The captured baseline stays fixed while you edit the proposed inputs below. Edit baseline inputs loads it into the working form; capture again to save your changes. Differences are proposed minus baseline, without a better/worse judgement.
- Worst case (ms)
- Baseline: 65,000
- Proposed: 65,000
- Difference: 0
- Expected duration (ms)
- Baseline: 65,000
- Proposed: 65,000
- Difference: 0
- Amplification (times)
- Baseline: 125
- Proposed: 125
- Difference: 0
Save inputs locally to resume this tool. Files may contain sensitive entered information; review before sharing. No automatic storage or transmission. Report JSON is an output record, not an input import format.
The first call plus every retry.
The first backoff. Exponential doubles it each time.
Caps the backoff so exponential growth stays bounded.
How long one call waits before it counts as failed.
When whoever is waiting gives up. For a synchronous API this is the client timeout.
Each layer applying this same policy. Gateway → service → database is three.
Traffic entering the top of the chain.
Worst case
1m 5s
Before the caller is told it failed
Expected
1m 5s
Same as worst case without jitter
Amplification
125×
One request becomes 125 at the deepest layer
Attempt timeline
- Attempt in time
- Starts after the deadline
- Deadline · 30s
| Attempt | Waits | Starts at | Failed by |
|---|---|---|---|
| 1 | — | 0ms | 10s |
| 2 | 1s | 11s | 21s |
| 3 | 2s | 23s | 33s |
| 4 · | 4s | 37s | 47s |
| 5 · | 8s | 55s | 1m 5s |
Critical
2 of 5 attempts happen after the caller has given up
The caller's deadline is 30s, but attempt 4 does not even start until 37s. Those attempts cannot help anyone — the response has nowhere to go — while still consuming a connection, a thread and a database handle on a system that is already failing. This is the configuration that turns a slow dependency into an outage.
Critical
One request at the top becomes up to 125 at the bottom
5 attempts at each of 3 layers multiply rather than add. At 50 req/s entering the chain, the deepest service can see 6,250 req/s — 99% of which is retries. Each layer's policy looks reasonable on its own; nobody owns the product. This is why a small dependency blip becomes a full outage.
Critical
No jitter — every client retries at the same instant
Clients that fail together back off by identical amounts and therefore return together. The recovering service is hit by the entire population at 1s, fails again, and the herd re-forms. Full jitter — a random wait between zero and the computed backoff — spreads the same load across the window and costs nothing.
Deterministic: jitter is modelled as a range rather than sampled, so the same inputs always give the same answer. The number worth carrying away is the amplification — retries compose multiplicatively down a chain, and it is the one figure nobody owns, because each layer's policy looks reasonable on its own.
More in this category
These exist because the underlying problem is real. If the numbers you just put in look uncomfortable, that is usually worth a conversation.
Stay ahead of the integration layer.
Integronauts Signal — practical enterprise integration, API and agentic AI thinking. The tools stay free either way.
Integronauts Signal is launching soon.
Practical enterprise integration, APIs, agentic AI and emerging architecture. Sign-up opens when the list does — nothing to enter yet.