Limits — Cloudflare Workers docs
Summary
This Cloudflare Workers documentation page, last updated Oct 12, 2026, lists the platform's limits on the Workers Free and Workers Paid plans. Free accounts get 100,000 requests per day and 10 ms of CPU time per HTTP request; Paid accounts have no request limit and a default of 30 seconds of CPU time, which can be raised to 5 minutes (300,000 ms). Each isolate can use up to 128 MB of memory, a Worker may be up to 64 MiB uncompressed and must start within 1 second, and each invocation may have up to six connections waiting for response headers. Subrequests are capped at 50 per invocation on Free and 10,000 on Paid, and accounts may hold 100 or 500 Workers. Cron Triggers, Queue consumers and Durable Object alarms run for up to 15 minutes, while HTTP requests have no hard duration limit while the client stays connected.
Summary drafted by a model from the document's text below and checked by script against that text before publication. It is a navigation aid, not a reading of what the document proves. Where AI is used
Full text
Limits
Last updated Oct 12, 2026 | | View as Markdown | Agent setup
Account plan limits
Feature | Workers Free | Workers Paid
Requests | 100,000/day | No limit
CPU time | 10 ms | 5 min
Memory | 128 MB | 128 MB
Subrequests | 50/request | 10,000/request
Simultaneous outgoing connections/request | 6 | 6
Environment variables | 64/Worker | 128/Worker
Environment variable size | 5 KB | 5 KB
Worker size | 64 MiB | 64 MiB
Worker startup time | 1 second | 1 second
Number of Workers | 100 | 500 1
Number of Cron Triggers per account | 5 | 250
Number of Static Asset files per Worker version | 20,000 | 100,000
Individual Static Asset file size | 25 MiB | 25 MiB
Request and response limits
Limit | Value
URL size | 16 KB
Request header size | 128 KB (total)
Response header size | 128 KB (total)
Response body size | No enforced limit
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.
Cloudflare Plan | Maximum request body size
Free | 100 MB
Pro | 100 MB
Business | 200 MB
Enterprise | Up to 5 GB (self-serve)
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.
Limit | Workers Free | Workers Paid
CPU time per HTTP request | 10 ms | 5 min (default: 30 seconds)
CPU time per Cron Trigger | 10 ms | 30 seconds (< 1 hour interval) 15 min (>= 1 hour interval)
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:
- 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.
- Optimize your code — Use CPU profiling with DevTools to identify CPU-intensive sections of your code.
- 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
Limit | Value
Memory per isolate | 128 MB
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:
- Stream request and response bodies — Use TransformStream or node:stream instead of buffering entire payloads in memory.
- Avoid large in-memory objects — Store large data in KV , R2 , or D1 instead of holding it in Worker memory.
- Update Zod — If your Worker uses Zod, use version 4.5.0 or later ↗︎ . Earlier versions use substantially more memory per schema.
- Profile memory usage — Use memory profiling with DevTools locally to identify leaks and high-memory allocations.
To view memory errors in the dashboard:
- Go to Workers & Pages . Go to Workers & Pages ↗
- Select the Worker you want to investigate.
- Under Metrics , select Errors > Invocation Statuses and examine Exceeded Memory .
Duration
Duration measures wall-clock time from start to end of a Worker invocation.
Trigger type | Duration limit
HTTP request | No limit
Cron Trigger | 15 min
Durable Object Alarm | 15 min
Queue Consumer | 15 min
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 .
Route mode | Behavior
Fail open | Bypasses the Worker. Requests behave as if no Worker is configured.
Fail closed | Returns a Cloudflare 1027 error page. Use this for security-critical Workers.
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 .
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 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
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:
src/index.js js
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();
}
src/index.ts ts
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();
}
Environment variables
Limit | Workers Free | Workers Paid
Variables per Worker (secrets + text) | 64 | 128
Variable size | 5 KB | 5 KB
Variables per account | No limit | No limit
Worker size
Limit | Workers Free | Workers Paid
Worker size (uncompressed) | 64 MiB | 64 MiB
There is no compressed size limit. Only the uncompressed bundle size counts.
Larger Worker bundles can impact startup time. To check your Worker bundle size:
wrangler deploy --outdir bundled/ --dry-run
Total Upload: 259.61 KiB / gzip: 47.23 KiB
The Total Upload value is your uncompressed bundle size. The gzip value is shown for reference but is not a limit.
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 .
Worker startup time
Limit | Value
Startup time | 1 second
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.
Number of Workers
Limit | Workers Free | Workers Paid
Workers per account | 100 | 500 1
If you are building a platform where your end customers deploy their own sites or applications, use Workers for Platforms , which runs an unlimited number of user Workers.
Routes and domains
Limit | Value
Routes per zone | 1,000
Routes per zone ( wrangler dev --remote ) | 50
Custom domains per zone | 100
Routed zones per Worker | 1,000
Routes with wrangler dev --remote
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 .
Cache API limits
Feature | Workers Free | Workers Paid
Maximum object size | 512 MB | 512 MB
Calls per request | 50 | 1,000
Calls per request is the number of put() , match() , or delete() Cache API calls per request. This shares the same quota as subrequests ( fetch() ).
Log size
Limit | Value
Log data per request | 256 KB
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.
Image Resizing with Workers
Refer to the Image Resizing documentation for limits that apply when using Image Resizing with Workers.
Static Assets
Limit | Workers Free | Workers Paid
Files per Worker version | 20,000 | 100,000
Individual file size | 25 MiB | 25 MiB
_headers rules | 100 | 100
_headers characters per line | 2,000 | 2,000
_redirects static redirects | 2,000 | 2,000
_redirects dynamic redirects | 100 | 100
_redirects total | 2,100 | 2,100
_redirects characters per rule | 1,000 | 1,000
Unbound and Bundled plan limits
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:
Feature | Bundled plan limit
Subrequests | 50/request
CPU time (HTTP requests) | 50 ms
CPU time (Cron Triggers) | 50 ms
Cache API calls/request | 50
Bundled plan Workers have no duration limits for Cron Triggers , Durable Object Alarms , or Queue Consumers .
Wall time limits by invocation type
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:
Invocation type | Wall time limit | Details
Incoming HTTP request | Unlimited | No hard limit while the client remains connected. Workers requests are subject to the grace period for runtime updates . A Worker that is still streaming a response body remains active. waitUntil() extends execution for up to 30 seconds after the response or disconnect.
Cron Triggers | 15 minutes | Scheduled Workers have a maximum wall time of 15 minutes per invocation.
Queue consumers | 15 minutes | Each consumer invocation has a maximum wall time of 15 minutes.
Durable Object alarm handlers | 15 minutes | Alarm handler invocations have a maximum wall time of 15 minutes.
Durable Objects (RPC / HTTP) | Unlimited | No hard limit while the caller stays connected to the Durable Object. Durable Objects remain active while a request, RPC call, response stream, WebSocket, or pending I/O is in flight.
Workflows (per step) | Unlimited | Each step can run for an unlimited wall time. Individual steps are subject to the configured CPU time limit .
Related resources
Footnotes
- If you need a higher Worker limit, use Workers for Platforms . ↩ ↩ 2
Was this helpful?
File and source
- File
- WB076.html
- Size
- 250,556 bytes
- SHA-256
- 39599b515864590e5a8765d7b30b34ebeb3a24372f08d4231592a57dde39687a
- Our copy
- WB076.html
- Original
- No public link identified.