# A request budget is not durable execution

On HTTP-triggered Cloudflare Workers, `ctx.waitUntil` can extend execution for up to **30 seconds after the response is sent or the client disconnects**. The allowance is shared across that request's waitUntil calls. It is not a total HTTP wall-time limit while a response remains active. Unsettled background work can be canceled at the end of the allowance.

Source: [Cloudflare Workers Context: waitUntil](https://developers.cloudflare.com/workers/runtime-apis/context/), checked 2026-10-23. This platform reference supplements the book bibliography; it is not a book quotation.

## Worked example: three attempts do not fit

This is an illustrative design calculation, not a report about a private service.

| Plan | Worst-case waiting |
| --- | --- |
| Three attempts, each allowed 20 seconds | 60 seconds before backoff and bookkeeping |
| The same attempts with another 6 seconds of delay/overhead | 66 seconds |
| One 25-second end-to-end budget | At most the chosen budget for cooperative work, not a fresh 25 seconds per attempt |

A post-response allowance of up to 30 seconds cannot accommodate a plan that needs 66 seconds. Smaller per-attempt limits alone do not fix the total unless retries share one budget.

Our proposed composition:

1. Persist an undelivered marker and stable operation identity before acknowledging required work.
2. Choose one absolute deadline for this execution pass. A 25-second default leaves nominal margin below the post-response ceiling; it is an example setting, not a platform guarantee.
3. Carry that same deadline through retries. For each attempt, compute remaining time and cap its wait to the smaller of that remainder and the attempt limit.
4. Do not start another attempt when the budget is exhausted. Backoff consumes the same budget.
5. Clear or transition the marker only after confirmed delivery. On uncertain remote success, preserve uncertainty and reconcile or use receiver-enforced idempotency before repeating.
6. Let a durable owner discover undelivered work and redrive it independently of the original request. Each later pass gets a new bounded budget but keeps the operation identity.

A numeric deadline policy can use `Context.Reference` when a default is intentional. Compute the absolute deadline for each pass; do not cache a clock-derived absolute deadline as the reference's default. The storage service remains an explicit required dependency, not a default reference.

Our Effect 4.0.5 reading: `Context.Reference` defines a context key with a lazily computed, cached default; `Effect.timeout` bounds interruptible waiting. Source: `packages/effect/src/Context.ts:1321-1372` and `packages/effect/src/Effect.ts`. Neither API persists the undelivered marker or guarantees a remote write was canceled.

## Proof to collect

- Drive three slow attempts with virtual time and show that total waiting plus delays uses one budget.
- End the request and cancel its background work. Verify the undelivered marker remains discoverable.
- Redrive from the durable owner. Prove duplicate safety at the receiver and eventual marker transition after confirmed success.
- Test uncertain remote success separately from confirmed non-delivery.

See [timeouts](https://uncomplect.com/principles/timeouts-bound-waiting), [idempotency](https://uncomplect.com/principles/retry-needs-idempotency), and [request lifetime](https://uncomplect.com/principles/request-lifetime-is-not-durability). The operational distinction follows Nygard's timeouts/delayed retry and Reis/Housley's idempotency; the concrete Worker ceiling comes from the platform documentation.