Skip to content

Fixed Workers duration limits in 6 files. #30871

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ask-bonk wants to merge 6 commits into
base: production
Choose a base branch
from
Open

Fixed Workers duration limits in 6 files. #30871

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
30ab98a
Fixed Workers duration limits in 6 files.
ask-bonk[bot] May 17, 2026
c4d854a
Clarify Workers waitUntil duration semantics
irvinebroque May 18, 2026
66b597a
Clarify waitUntil best practice guidance
irvinebroque May 18, 2026
574b958
Refine scheduled waitUntil note
irvinebroque May 18, 2026
267a9d9
Refine waitUntil post-response guidance
irvinebroque May 18, 2026
998533e
Restore unlimited wall time labels
irvinebroque May 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/content/docs/durable-objects/api/state.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,11 +77,11 @@ Contains loopback bindings to the Worker's own top-level exports. This has exact

### `waitUntil`

`waitUntil` waits until the promise which is passed as a parameter resolves, and can extend a request context even after the last client disconnects. Refer to [Lifecycle of a Durable Object](/durable-objects/concepts/durable-object-lifecycle/) for more information.
`waitUntil` is available on `DurableObjectState` for API compatibility with [Workers Runtime APIs](/workers/runtime-apis/context/#waituntil).

:::note[`waitUntil` has no effect in Durable Objects]

Unlike in Workers, `waitUntil` has no effect in Durable Objects. It exists only for API compatibility with the [Workers Runtime APIs](/workers/runtime-apis/context/#waituntil).
Unlike in Workers, `waitUntil` has no effect in Durable Objects. It does not extend the lifetime of a Durable Object or affect when a request or RPC completes.

Durable Objects automatically remain active as long as there is ongoing work or pending I/O, so `waitUntil` is not needed. Refer to [Lifecycle of a Durable Object](/durable-objects/concepts/durable-object-lifecycle/) for more information.
:::
Expand Down
8 changes: 6 additions & 2 deletions src/content/docs/workers/best-practices/workers-best-practices.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -277,9 +277,11 @@ For more information, refer to [Streams](/workers/runtime-apis/streams/).

### Use waitUntil for work after the response

[`ctx.waitUntil()`](/workers/runtime-apis/context/) lets you perform work after the response is sent to the client, such as analytics, cache writes, non-critical logging, or webhook notifications. This keeps your response fast while still completing background tasks.
[`ctx.waitUntil()`](/workers/runtime-apis/context/) lets you perform work after the response is sent to the client, such as analytics, cache writes, logging, or webhook notifications. This keeps your response fast while still completing background tasks.

There are two common pitfalls: destructuring `ctx` (which loses the `this` binding and throws "Illegal invocation"), and exceeding the 30-second `waitUntil` time limit after the response is sent.
Use `ctx.waitUntil()` only for work that does not affect the response. If the response depends on the work, `await` it before returning the response or stream the response as the work completes. A Worker that is still streaming a response body remains active without `ctx.waitUntil()`.

There are two common pitfalls: destructuring `ctx` (which loses the `this` binding and throws "Illegal invocation"), and exceeding the 30-second `waitUntil()` time limit after the response is sent or the client disconnects.

<TypeScriptExample filename="src/index.ts">

Expand Down Expand Up @@ -747,6 +749,8 @@ For more information, refer to [Workers errors](/workers/observability/errors/#c

A `Promise` that is not `await`ed, `return`ed, or passed to `ctx.waitUntil()` is a floating promise. Floating promises cause silent bugs: dropped results, swallowed errors, and unfinished work. The Workers runtime may terminate your isolate before a floating promise completes.

Choose based on whether the response depends on the work. Use `await` or `return` for work that must complete before the response is correct. Use `ctx.waitUntil()` for work that can run after the response is sent and can finish within the `waitUntil()` time limit.

Enable the `no-floating-promises` lint rule to catch these at development time. If you use ESLint, enable [`@typescript-eslint/no-floating-promises`](https://typescript-eslint.io/rules/no-floating-promises/). If you use oxlint, enable [`typescript/no-floating-promises`](https://oxc.rs/docs/guide/usage/linter/rules/typescript/no-floating-promises.html).

```bash
Expand Down
60 changes: 30 additions & 30 deletions src/content/docs/workers/observability/errors.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,22 +15,21 @@ Review Workers errors and exceptions.

When a Worker running in production has an error that prevents it from returning a response, the client will receive an error page with an error code, defined as follows:

| Error code | Meaning |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `1101` | Worker threw a JavaScript exception. |
| `1102` | Worker exceeded [CPU time limit](/workers/platform/limits/#cpu-time). |
| `1103` | The owner of this worker needs to contact [Cloudflare Support](/support/contacting-cloudflare-support/) |
| `1019` | Worker hit [loop limit](#loop-limit). |
| `1021` | Worker has requested a host it cannot access. |
| `1022` | Cloudflare has failed to route the request to the Worker. |
| `1024` | Worker cannot make a subrequest to a Cloudflare-owned IP address. |
| `1027` | Worker exceeded free tier [daily request limit](/workers/platform/limits/#daily-requests). |
| Error code | Meaning |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `1101` | Worker threw a JavaScript exception. |
| `1102` | Worker exceeded [CPU time limit](/workers/platform/limits/#cpu-time). |
| `1103` | The owner of this worker needs to contact [Cloudflare Support](/support/contacting-cloudflare-support/) |
| `1019` | Worker hit [loop limit](#loop-limit). |
| `1021` | Worker has requested a host it cannot access. |
| `1022` | Cloudflare has failed to route the request to the Worker. |
| `1024` | Worker cannot make a subrequest to a Cloudflare-owned IP address. |
| `1027` | Worker exceeded free tier [daily request limit](/workers/platform/limits/#daily-requests). |
| `1042` | Worker tried to fetch from another Worker on the same zone, which is only [supported](/workers/runtime-apis/fetch/) when the [`global_fetch_strictly_public` compatibility flag](/workers/configuration/compatibility-flags/#global-fetch-strictly-public) is used. |
| `10162` | Module has an unsupported Content-Type. |
| `10162` | Module has an unsupported Content-Type. |

Other `11xx` errors generally indicate a problem with the Workers runtime itself. Refer to the [status page](https://www.cloudflarestatus.com) if you are experiencing an error.


### Loop limit

A Worker cannot call itself or another Worker more than 16 times. In order to prevent infinite loops between Workers, the [`CF-EW-Via`](/fundamentals/reference/http-headers/#cf-ew-via) header's value is an integer that indicates how many invocations are left. Every time a Worker is invoked, the integer will decrement by 1. If the count reaches zero, a [`1019`](#error-pages-generated-by-workers) error is returned.
Expand Down Expand Up @@ -191,23 +190,23 @@ If you need to share state across requests, consider using [Durable Objects](/du

These errors occur when a Worker is uploaded or modified.

| Error code | Meaning |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `10006` | Could not parse your Worker's code. |
| `10007` | Worker or [workers.dev subdomain](/workers/configuration/routing/workers-dev/) not found. |
| `10015` | Account is not entitled to use Workers. |
| `10016` | Invalid Worker name. |
| `10021` | Validation Error. Refer to [Validation Errors](/workers/observability/errors/#validation-errors-10021) for details. |
| `10026` | Could not parse request body. |
| `10027` | The uploaded Worker exceeded the [Worker size limits](/workers/platform/limits/#worker-size). |
| `10035` | Multiple attempts to modify a resource at the same time |
| `10037` | An account has exceeded the number of [Workers allowed](/workers/platform/limits/#number-of-workers). |
| `10052` | A [binding](/workers/runtime-apis/bindings/) is uploaded without a name. |
| `10054` | A environment variable or secret exceeds the [size limit](/workers/platform/limits/#environment-variables). |
| `10055` | The number of environment variables or secrets exceeds the [limit/Worker](/workers/platform/limits/#environment-variables). |
| `10056` | [Binding](/workers/runtime-apis/bindings/) not found. |
| `10068` | The uploaded Worker has no registered [event handlers](/workers/runtime-apis/handlers/). |
| `10069` | The uploaded Worker contains [event handlers](/workers/runtime-apis/handlers/) unsupported by the Workers runtime. |
| Error code | Meaning |
| ---------- | --------------------------------------------------------------------------------------------------------------------------- |
| `10006` | Could not parse your Worker's code. |
| `10007` | Worker or [workers.dev subdomain](/workers/configuration/routing/workers-dev/) not found. |
| `10015` | Account is not entitled to use Workers. |
| `10016` | Invalid Worker name. |
| `10021` | Validation Error. Refer to [Validation Errors](/workers/observability/errors/#validation-errors-10021) for details. |
| `10026` | Could not parse request body. |
| `10027` | The uploaded Worker exceeded the [Worker size limits](/workers/platform/limits/#worker-size). |
| `10035` | Multiple attempts to modify a resource at the same time |
| `10037` | An account has exceeded the number of [Workers allowed](/workers/platform/limits/#number-of-workers). |
| `10052` | A [binding](/workers/runtime-apis/bindings/) is uploaded without a name. |
| `10054` | A environment variable or secret exceeds the [size limit](/workers/platform/limits/#environment-variables). |
| `10055` | The number of environment variables or secrets exceeds the [limit/Worker](/workers/platform/limits/#environment-variables). |
| `10056` | [Binding](/workers/runtime-apis/bindings/) not found. |
| `10068` | The uploaded Worker has no registered [event handlers](/workers/runtime-apis/handlers/). |
| `10069` | The uploaded Worker contains [event handlers](/workers/runtime-apis/handlers/) unsupported by the Workers runtime. |

### Validation Errors (10021)

Expand Down Expand Up @@ -236,6 +235,7 @@ Runtime errors will occur within the runtime, do not throw up an error page, and
## Identify errors: Workers Metrics

To review whether your application is experiencing any downtime or returning any errors:

1. In the Cloudflare dashboard, go to the **Workers & Pages** page.

<DashButton url="/?to=/:account/workers-and-pages" />
Expand Down Expand Up @@ -278,7 +278,7 @@ Exceptions will show up under the `exceptions` field in the JSON returned by `wr

A Worker can make HTTP requests to any HTTP service on the public Internet. You can use a service like [Sentry](https://sentry.io) to collect error logs from your Worker, by making an HTTP request to the service to report the error. Refer to your service’s API documentation for details on what kind of request to make.

When using an external logging strategy, remember that outstanding asynchronous tasks are canceled as soon as a Worker finishes sending its main response body to the client. To ensure that a logging subrequest completes, pass the request promise to [`event.waitUntil()`](https://developer.mozilla.org/en-US/docs/Web/API/ExtendableEvent/waitUntil). For example:
When using an external logging strategy, remember that floating promises (promises that are neither `await`ed, `return`ed, nor passed to `ctx.waitUntil()`) may be canceled when the Worker invocation completes. A Worker invocation has not completed while it is still streaming a response body to the client. To run logging after the response is complete, pass the request promise to [`ctx.waitUntil()`](/workers/runtime-apis/context/#waituntil). For example:

<Tabs> <TabItem label="Module Worker" icon="seti:javascript">

Expand Down
19 changes: 12 additions & 7 deletions src/content/docs/workers/platform/limits.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,12 @@ products:
- workers
---

import { Render, WranglerConfig, DashButton, TypeScriptExample } from "~/components";
import {
Render,
WranglerConfig,
DashButton,
TypeScriptExample,
} from "~/components";

## Account plan limits

Expand Down Expand Up @@ -146,7 +151,7 @@ To view memory errors in the dashboard:

## Duration

Duration measures wall-clock time from start to end of a Worker invocation. There is no hard limit on duration for HTTP-triggered Workers. As long as the client remains connected, the Worker can continue processing, making subrequests, and setting timeouts.
Duration measures wall-clock time from start to end of a Worker invocation.

| Trigger type | Duration limit |
| ----------------------------------------------------------------- | -------------- |
Expand All @@ -155,7 +160,7 @@ Duration measures wall-clock time from start to end of a Worker invocation. Ther
| [Durable Object Alarm](/durable-objects/api/alarms/) | 15 min |
| [Queue Consumer](/queues/configuration/javascript-apis/#consumer) | 15 min |

When the client disconnects, all tasks associated with that request are canceled. Use [`event.waitUntil()`](/workers/runtime-apis/handlers/fetch/) to delay cancellation for another 30 seconds or until the promise you pass to `waitUntil()` completes.
There is no hard limit on duration for HTTP-triggered Workers. As long as the client remains connected, the Worker can continue processing, making subrequests, and streaming a response body. When the client disconnects or the response is complete, tasks associated with that request may be canceled. Use [`ctx.waitUntil()`](/workers/runtime-apis/context/#waituntil) to perform work after returning a response. `waitUntil()` can extend execution for up to 30 seconds after the response is sent or the client disconnects.

:::note

Expand Down Expand Up @@ -183,14 +188,14 @@ You can configure the fail mode by toggling the corresponding [route](/workers/c

A subrequest is any request a Worker makes using the [Fetch API](/workers/runtime-apis/fetch/) or to Cloudflare services like [R2](/r2/), [KV](/kv/), or [D1](/d1/).

| Limit | Workers Free | Workers Paid |
| -------------------------------- | ------------ | ---------------------- |
| Subrequests per invocation | 50 | 10,000 (up to 10M) |
| Limit | Workers Free | Workers Paid |
| -------------------------------- | ------------ | ----------------------------------------- |
| Subrequests per invocation | 50 | 10,000 (up to 10M) |
| Subrequests to internal services | 1,000 | Matches configured limit (default 10,000) |

Each subrequest in a redirect chain counts against this limit. The total number of subrequests may exceed the number of `fetch()` calls in your code. You can change the subrequest limit per Worker using the [`limits` configuration](/workers/wrangler/configuration/#limits) in your Wrangler configuration file.

There is no set time limit on individual subrequests. As long as the client remains connected, the Worker can continue making subrequests. When the client disconnects, all tasks are canceled. Use [`event.waitUntil()`](/workers/runtime-apis/handlers/fetch/) to delay cancellation for up to 30 seconds.
There is no set time limit on individual subrequests. As long as the client remains connected, the Worker can continue making subrequests. When the client disconnects or the response is complete, outstanding work may be canceled unless it is passed to [`ctx.waitUntil()`](/workers/runtime-apis/context/#waituntil), which can extend execution for up to 30 seconds.

### Worker-to-Worker subrequests

Expand Down
Loading