Limits

¹ If you reach this limit, consider using Workers for Platforms.

Request body size limits depend on your Cloudflare account plan, not your Workers plan. Requests exceeding these limits return a 413 Request entity too large error.

Enterprise customers can contact their account team or Cloudflare Support for a higher request body limit.

Cloudflare does not enforce response body size limits. CDN cache limits apply: 512 MB for Free, Pro, and Business plans, and 5 GB for Enterprise.

CPU time measures how long the CPU spends executing your Worker code. Waiting on network requests (such as fetch() calls, KV reads, or database queries) does not count toward CPU time.

Most Workers consume very little CPU time. The average Worker uses approximately 2.2 ms per request. Heavier workloads that handle authentication, server-side rendering, or parse large payloads typically use 10-20 ms.

Each isolate has some built-in flexibility to allow for cases where your Worker infrequently runs over the configured limit. If your Worker starts hitting the limit consistently, its execution will be terminated according to the limit configured.

When a Worker exceeds its CPU time limit, Cloudflare returns Error 1102 to the client with the message Worker exceeded resource limits. In the dashboard, this appears as Exceeded CPU Time Limits under Metrics > Errors > Invocation Statuses. In analytics and Logpush, the invocation outcome is exceededCpu.

To resolve a CPU time limit error:

1. Increase the CPU time limit — On the Workers Paid plan, you can raise the limit from the default 30 seconds up to 5 minutes (300,000 ms). Set this in your Wrangler configuration or in the dashboard.
2. Optimize your code — Use CPU profiling with DevTools to identify CPU-intensive sections of your code.
3. Offload work — Move expensive computation to Durable Objects or process data in smaller chunks across multiple requests.

On the Workers Paid plan, you can increase the maximum CPU time from the default 30 seconds to 5 minutes (300,000 ms).

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000, // default is 30000 (30 seconds)
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

You can also change this in the dashboard: go to Workers & Pages > select your Worker > Settings > adjust the CPU time limit.

• Workers Logs — CPU time and wall time appear in the invocation log.
• Tail Workers / Logpush — CPU time and wall time appear at the top level of the Workers Trace Events object.
• DevTools — Use CPU profiling with DevTools locally to identify CPU-intensive sections of your code.

Each isolate can consume up to 128 MB of memory, including the JavaScript heap and WebAssembly allocations. This limit is per-isolate, not per-invocation. A single isolate can handle many concurrent requests.

When an isolate exceeds 128 MB, the Workers runtime lets in-flight requests complete and creates a new isolate for subsequent requests. During extremely high load, the runtime may cancel some incoming requests to maintain stability.

When a Worker exceeds its memory limit, Cloudflare returns Error 1102 to the client with the message Worker exceeded resource limits. In the dashboard, this appears as Exceeded Memory under Metrics > Errors > Invocation Statuses. In analytics and Logpush, the invocation outcome is exceededMemory.

You may also see the runtime error Memory limit would be exceeded before EOF when attempting to buffer a response body that exceeds the limit.

To resolve a memory limit error:

1. Stream request and response bodies — Use TransformStream or node:stream instead of buffering entire payloads in memory.
2. Avoid large in-memory objects — Store large data in KV, R2, or D1 instead of holding it in Worker memory.
3. Profile memory usage — Use memory profiling with DevTools locally to identify leaks and high-memory allocations.

To view memory errors in the dashboard:

1. Go to Workers & Pages.

   Go to Workers & Pages ↗

2. Select the Worker you want to investigate.

3. Under Metrics, select Errors > Invocation Statuses and examine Exceeded Memory.

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 streaming a response body. When the client disconnects or the response is complete, tasks associated with that request may be canceled. Use ctx.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.

Workers scale automatically across the Cloudflare global network. There is no general limit on requests per second.

Accounts on the Workers Free plan have a daily request limit of 100,000 requests, resetting at midnight UTC. When a Worker exceeds this limit, Cloudflare returns Error 1027.

You can configure the fail mode by toggling the corresponding route.

A subrequest is any request a Worker makes using the Fetch API or to Cloudflare services like R2, KV, or D1.

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 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 or the response is complete, outstanding work may be canceled unless it is passed to ctx.waitUntil(), which can extend execution for up to 30 seconds.

Use Service Bindings to send requests from one Worker to another on your account without going over the Internet.

Using global fetch() to call another Worker on the same zone without service bindings fails. Workers accept requests sent to a Custom Domain.

Each Worker invocation can have up to six connections simultaneously waiting for response headers. The following API calls count toward this limit while the initial connection is being established and the server has not yet responded:

• fetch() method of the Fetch API
• get(), put(), list(), and delete() methods of Workers KV namespace objects
• put(), match(), and delete() methods of Cache objects
• list(), get(), put(), delete(), and head() methods of R2
• send() and sendBatch() methods of Queues
• Opening a TCP socket using the connect() API

Outbound WebSocket connections also count toward this limit.

Once response headers arrive for a connection, it no longer counts toward the six-connection limit. This means a Worker can have many connections open simultaneously, as long as no more than six are in the initial "waiting for headers" phase at the same time. If a seventh connection is attempted while six are already waiting for headers, it is queued until one of the existing connections receives its response headers.

If you use fetch() but do not need the response body, calling response.body.cancel() is still good practice to free memory:

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

const response = await fetch(url);

// Only read the response body for successful responses
if (response.status <= 299) {
	// Call response.json(), response.text() or otherwise process the body
} else {
	// Explicitly cancel it
	response.body.cancel();
}

Larger Worker bundles can impact startup time. To check your compressed bundle size:

wrangler deploy --outdir bundled/ --dry-run

# Output will resemble the below:
Total Upload: 259.61 KiB / gzip: 47.23 KiB

To reduce Worker size:

• Remove unnecessary dependencies and packages.
• Store configuration files, static assets, and binary data in KV, R2, D1, or Workers Static Assets instead of bundling them.
• Split functionality across multiple Workers using Service bindings.

A Worker must parse and execute its global scope (top-level code outside of handlers) within 1 second. Larger bundles and expensive initialization code in global scope increase startup time.

When the platform rejects a deployment because the Worker exceeds the startup time limit, the validation returns the error Script startup exceeded CPU time limit (error code 10021). Wrangler automatically generates a CPU profile that you can import into Chrome DevTools or open in VS Code. Refer to wrangler check startup for more details.

To measure startup time, run npx wrangler@latest deploy or npx wrangler@latest versions upload. Wrangler reports startup_time_ms in the output.

To reduce startup time, avoid expensive work in global scope. Move initialization logic into your handler or to build time. For example, generating or consuming a large schema at the top level is a common cause of exceeding this limit.

If you need more than 500 Workers, consider using Workers for Platforms.

When you run a remote development session using the --remote flag, Cloudflare enforces a limit of 50 routes per zone. The Quick Editor in the Cloudflare dashboard also uses wrangler dev --remote, so the same limit applies.

If your zone has more than 50 routes, you cannot run a remote session until you remove routes to get under the limit.

If you require more than 1,000 routes or 1,000 routed zones per Worker, consider using Workers for Platforms. If you require more than 100 custom domains per zone, consider using a wildcard route.

Calls per request is the number of put(), match(), or delete() Cache API calls per request. This shares the same quota as subrequests (fetch()).

This limit covers all data emitted via console.log() statements, exceptions, request metadata, and headers for a single request. After exceeding this limit, the system does not record additional context for that request in logs, tail logs, or Tail Workers.

Refer to the Workers Trace Event Logpush documentation for limits on fields sent to Logpush destinations.

Refer to the Image Resizing documentation for limits that apply when using Image Resizing with Workers.

If your Worker is on an Unbound plan, limits match the Workers Paid plan.

If your Worker is on a Bundled plan, limits match the Workers Paid plan with these exceptions:

Bundled plan Workers have no duration limits for Cron Triggers, Durable Object Alarms, or Queue Consumers.

Wall time (also called wall-clock time) is the total elapsed time from the start to end of an invocation, including time spent waiting on network requests, I/O, and other asynchronous operations. This is distinct from CPU time, which only measures time the CPU spends actively executing your code.

The following table summarizes the wall time limits for different types of Worker invocations across the developer platform:

• KV limits
• Durable Object limits
• Queues limits
• Workers errors reference