Background jobs / Policy workbench

Retry Budget & Amplification Workbench

How much extra work can the SDK, application, and job runner create before the deadline?

Interactive calculations run in your browser; the initial example is pre-rendered. There are no accounts, uploads, or live queue connections. Inputs stay in page memory; the site does not persist them, put them in URLs, or send them to analytics. A worksheet download includes only what you explicitly export.

Describe the nested retry policies

Attempt limits include the initial try. Each outer attempt reruns the full inner policy; calls are assumed to time out from the caller's perspective, without establishing their downstream effects.

SDK: innermost

SDK: innermost attempt limit

1 means this layer does not retry.

Initial backoff (ms)

Maximum backoff (ms)

Application

Application attempt limit

1 means this layer does not retry.

Initial backoff (ms)

Maximum backoff (ms)

Job runner: outermost

Job runner: outermost attempt limit

1 means this layer does not retry.

Initial backoff (ms)

Maximum backoff (ms)

Physical attempt timeout (ms)

End-to-end deadline (ms)

Backoff jitter

Teaching jitter seed

The same seed produces the same illustration.

Attempt bounds and illustrated timeline

Maximum downstream attempts

Without a deadline; every layer exhausts

Attempts started in this trace

Clipped by the absolute deadline

Illustrated elapsed time

10 s

Absolute deadline reached

Time spent in backoff

2.2 s

Included in the elapsed time

Multiple retry owners: sdk, application, runner. Account for every layer before choosing a single owner per dependency.

Without the deadline, maximum configured waits and failed-attempt time total 37.2 s. Full jitter selects a seeded delay from zero through each exponential backoff cap. One trace is not a statistical forecast.

Synthetic timeline; path is job runner.application.SDK attempt
Action	Attempt path	Start / end (ms)	Deadline boundary
attempt (sdk)	`1.1.1`	0 / 1,000	Full modeled interval
backoff (sdk)	`1.1.1`	1,000 / 1,100	Full modeled interval
attempt (sdk)	`1.1.2`	1,100 / 2,100	Full modeled interval
backoff (sdk)	`1.1.2`	2,100 / 2,300	Full modeled interval
attempt (sdk)	`1.1.3`	2,300 / 3,300	Full modeled interval
backoff (application)	`1.1`	3,300 / 3,800	Full modeled interval
attempt (sdk)	`1.2.1`	3,800 / 4,800	Full modeled interval
backoff (sdk)	`1.2.1`	4,800 / 4,900	Full modeled interval
attempt (sdk)	`1.2.2`	4,900 / 5,900	Full modeled interval
backoff (sdk)	`1.2.2`	5,900 / 6,100	Full modeled interval
attempt (sdk)	`1.2.3`	6,100 / 7,100	Full modeled interval
backoff (application)	`1.2`	7,100 / 8,100	Full modeled interval
attempt (sdk)	`1.3.1`	8,100 / 9,100	Full modeled interval
backoff (sdk)	`1.3.1`	9,100 / 9,200	Full modeled interval
attempt (sdk)	`1.3.2`	9,200 / 10,000	Clipped; remote outcome is not established

Assumptions and limits

Every client attempt is assumed to time out; actual downstream effects and success are not modeled.
The job runner calls the application policy, which calls the SDK policy. Attempt limits include the initial try.
One absolute deadline clips the last wait or attempt; cancellation does not prove a remote effect stopped.
Full jitter uses a seeded demonstration PRNG, not measured timing or production-ready randomness.