Limits (28)

Last updated Oct 12, 2026

Account plan limits

Need a higher limit?

To request an adjustment to a limit, complete the Limit Increase Request Form ↗︎. If the limit can be increased, Cloudflare will contact you with next steps.

Request and response limits

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 adjust the maximum request body size up to 5 GB themselves from the zone's Network page (Maximum Upload Size). For limits above 5 GB, contact your account team or Cloudflare Support.

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

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.

Error: exceeded CPU time limit

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.

Increasing the CPU time limit

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.

Monitoring CPU usage

• 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.

Memory

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.

Error: exceeded memory limit

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. Update Zod — If your Worker uses Zod, use version 4.5.0 or later ↗︎. Earlier versions use substantially more memory per schema.
4. 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

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.

Runtime updates

Cloudflare regularly updates the Workers runtime. During routine updates, processes running the previous version of the Workers runtime give existing Workers requests and connections up to 20 minutes to finish. This includes streaming HTTP responses and WebSocket connections.

Once the updated version of the Workers runtime is ready, it handles new incoming HTTP requests. Processes running the previous version stop accepting these requests and drain existing work during their grace period.

The grace period applies to each process running the previous version, not to each request. When it ends, that process terminates its remaining requests and connections.

Crashes, resource pressure, and shutdowns can interrupt work earlier. Design long-running applications to handle disconnections and safely retry interrupted work.

Daily requests

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.

Subrequests

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.

Worker-to-Worker subrequests

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.

Simultaneous open connections

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