Workers fetch subrequests and their limits

What counts as a subrequest

In a Cloudflare Worker, the incoming request that the worker handles is a single request. Any further call the worker code makes counts as a subrequest. The most common one is fetch() to another URL, but subrequests also include calls to Cloudflare services such as R2, KV and D1, and any subrequest that a Durable Object or Workflow triggers. Every one of these consumes space in the per-invocation subrequest budget.

The name is a trap for two reasons. First, a redirect chain inflates the count even though it is one fetch() call in your code: each hop in the chain is its own subrequest, so a URL that 301s twice counts as three subrequests. Second, a subrequest made in a Durable Object still counts against the budget of that object's invocation. The practical effect: long workers that fan out to many origins, or workers that call other Cloudflare services repeatedly, are the ones that hit the wall, not the simple single-fetch worker.

The Free plan default

On the Workers Free plan the default is 50 subrequests per invocation, split into two buckets:

• 50 external subrequests (fetches to the public internet), and
• 1,000 subrequests to Cloudflare services such as R2, KV and D1.

These are separate pools, so a worker doing 40 external fetches and 500 KV reads is within budget. But a worker that loops fetch() over 60 external URLs hits the 50 external cap and the invocation fails.

Free plan does not allow a raise

The Free plan caps do not have a configuring escape hatch: you cannot raise the 50 free external subrequests with a wrangler setting. The way past the Free limit is either to restructure the worker (bundle parallel fetches into one origin call, cache repeated lookups in KV, or move the fan-out to a queue or scheduled handler) or to move the worker to a Paid plan.

Paid plan default and raising it

On a Paid plan the default is 10,000 subrequests per invocation, covering both external and Cloudflare-service subrequests. That default was raised on 2026-02-11, when the historical 1,000 ceiling for paid workers became a default that can be increased. You can lower or raise it per worker in the Wrangler configuration:

{
  "limits": {
    "subrequests": 50000
  }
}

The maximum you can set is 10 million. The configuration names the budget bound; anything the worker does beyond it makes the invocation error rather than run uncontrolled. To protect against runaway code or unexpected costs you can set a lower figure, which also makes the cap the ceiling rather than relying on the default.

Practical guidance

• Profile first. Count the real worst case, including redirect hops, before changing a limit. A worker that appears to make 3 fetches can spend 9 subrequests if each origin URL redirects twice.
• Prefer fewer, larger requests over many small ones. Fetching a single JSON bundle beats 30 individual fetches.
• Keep heavy fan-out off the request path. Move multi-origin work to a scheduled handler, a queue consumer, or a Workflow, and return a fast response.
• Set an explicit limits.subrequests that matches reality so a regression is caught immediately.

The subrequest budget is one of the few limits a worker encounters at runtime rather than at deploy time, so knowing which plan you are on and what your fan-out really costs prevents a wall that only appears under load.