Workers memory limit is 128 MB
Workers have a 128 MB memory limit. Buffering entire large request or response bodies will cause your Worker to crash on large payloads.
Cloudflare Workers · all subjects
platform/limits
102 notes in this subject, read out of this brain and free to use. This is page 1 of 2.
ctx.waitUntil time limit is 30 seconds
The ctx.waitUntil() time limit is 30 seconds after the response is sent or the client disconnects.
Response size limits
Response size limits for Workers Caching are the same as Cloudflare's zone cache. At launch, all Workers Caching responses are subject to the Free plan size limit regardless of account plan. This restriction is temporary and will be lifted in a future update, after which limits will apply based on account plan.
Workers Cache billing table
Workers Cache billing: Cache HIT (Worker does not run) is charged at standard rate with no CPU time charge. Cache MISS (Worker runs) is charged at standard rate with CPU time billed. Cache BYPASS (Worker runs) is charged at standard rate with CPU time billed. Static asset requests are charged at standard rate with no CPU time. Worker-to-worker invocations are charged at standard rate with CPU time billed if Worker runs.
Workers Cache pricing
Workers Cache has no separate pricing. When you enable Workers Cache, all requests to your Worker are billed at the standard Workers request rate whether the response comes from cache or from your Worker. There is no charge beyond the standard request rate. CPU time is only billed when your Worker runs; cache hits do not consume CPU time. However, when caching is enabled, every request to your Worker is charged at the standard Workers request rate, including normally free requests like static asset requests and worker-to-worker invocations through service bindings or ctx.exports.
Build cache retention and storage limits
Cache is purged 7 days after its last read date. Unread cache artifacts are purged 7 days after creation. Every project is allocated 10 GB of storage. If the project cache exceeds this limit, the project automatically starts deleting artifacts that were read least recently.
Workers Builds environment specifications
Workers Builds run in Ubuntu 24.04 on x86_64 architecture.
Deploy Hook rate limits
Deploy Hooks are rate limited to 10 builds per minute per Worker and 100 builds per minute per account.
Environment variables limits
Workers Builds allows up to 64 custom environment variables per Worker, with each individual environment variable having a maximum size of 5 KB. These limits apply to both free and paid plans.
Concurrent builds definition
Concurrent builds is the number of builds that can run in parallel across an account in Workers Builds.
Workers Builds paid plan limits
Workers Builds paid plans have the following limits: 6,000 build minutes per month with additional usage charged at $0.005 per minute, 6 concurrent builds, 20 minute build timeout, 10 Deploy Hooks per minute per Worker and 100 per minute per account, 4 vCPU, 8 GB memory, 20 GB disk space, 64 environment variables with 5 KB maximum size per variable.
Build minutes definition
Build minutes is the number of minutes that it takes to build a project in Workers Builds.
Build timeout definition
Build timeout is the amount of time that a build can be run before it is terminated in Workers Builds. Both free and paid plans have a 20 minute timeout.
Deploy Hooks rate limit
Deploy Hooks have a rate limit of 10 per minute per Worker and 100 per minute per account. This limit applies to both free and paid plans.
Workers Builds CPU allocation
Workers Builds allocates 2 vCPU to free plan builds and 4 vCPU to paid plan builds.
Workers Builds memory allocation
Workers Builds allocates 8 GB of memory to builds on both free and paid plans.
Workers Builds disk space allocation
Workers Builds allocates 20 GB of disk space to builds on both free and paid plans.
Build timeout limit
There is a maximum build duration of 20 minutes. If a build exceeds this time, the build will be terminated with a 'Build was timed out' error.
523 errors on initial *.workers.dev deployment
When pushing a *.workers.dev subdomain for the first time, you may see 523 errors. These errors will resolve themselves after waiting a minute or so.
Workers pricing model
Cloudflare Workers is free to get started with flexible pricing that scales affordably at any scale.
Python version support window and security policy
Each Python release has a five-year support window. Once this support window has passed, security patches are no longer applied. Existing Python Workers on versions outside the support window will continue to work, but security patches are not provided. Using Python versions outside the support window for new projects is not recommended, and Cloudflare cannot guarantee performance for these older versions, which may suffer degraded performance including higher latency or CPU time usage.
Python Workers modules with limited functionality
The decimal module has only the C implementation (compiled to WebAssembly) available, not the Python implementation. The pydoc module does not have help messages for Python builtins. The webbrowser module is not available.
Python Workers excluded modules
The following Python modules are not available in Python Workers: curses, dbm, ensurepip, fcntl, grp, idlelib, lib2to3, msvcrt, pwd, resource, syslog, termios, tkinter, turtle.py, turtledemo, venv, winreg, winsound.
Python Workers non-functional modules
The multiprocessing and threading modules can be imported in Python Workers but are not functional due to the limitations of the WebAssembly VM.
Dependency size impact on Worker compilation
When adding new dependencies to Rust Workers, it is important to consider the impact on Worker size, as adding dependencies can significantly increase the total size of your Worker.
Remote development considerations and limitations
Remote development via 'wrangler dev --remote' has significantly slower iteration than local development due to upload/deployment step for each change. When using --remote flag, a limit of 50 routes per zone is enforced.
CPU-intensive tasks can cause slow responses or startup failures
If a Worker spends too much time performing CPU-intensive tasks, responses may be slow or the Worker might fail to startup due to time limits.
Worker memory limits and optimization
Understanding Worker memory usage can help you optimize performance, avoid Out of Memory (OOM) errors when hitting Worker memory limits, and fix memory leaks.
Loop limit: Workers cannot call each other more than 16 times
A Worker cannot call itself or another Worker more than 16 times. In order to prevent infinite loops between Workers, the 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 is returned.
OpenTelemetry export pricing and free period
Exporting OTel data is currently free for those on a Workers Paid subscription or higher during the early beta period. Starting October 1, 2026, tracing will be billed as part of your Workers Paid plan or contract. Workers Free plan does not support traces or logs export. Workers Paid plan includes 10 million trace events per month and 10 million log events per month, with additional events billed at $0.05 per million events.
Real-time logs maximum concurrent viewers
A maximum of 10 clients can view a Worker's logs at one time. This can be a combination of either dashboard sessions or wrangler tail calls.
Logpush truncation example for logs and exceptions
When the 16,384 character limit for logs and exceptions is exceeded, the truncation algorithm counts characters in this order: (1) all exception.names, (2) all exception.messages, (3) all log.messages. Once truncation begins for a field, that field is marked with "<<<Logpush: *field* truncated>>>" and subsequent messages in that field category are dropped. For example, if exception messages start being truncated, all subsequent log messages in that event will be dropped.
Minimum Wrangler version for source maps
Source maps require Wrangler version 3.46.0 or later. Check your Wrangler version by running `wrangler --version`.
Maximum source map size limit
The maximum source map size is 15 MB gzipped.
Changelog scope: not configurable changes
The Workers changelog documents meaningful changes made to Workers across the Cloudflare dashboard, Wrangler, the API, and the workerd runtime. These changes are not configurable.
Temporary account supported resources and capabilities
Temporary accounts support: Workers (deployments on workers.dev), Workers Static Assets (up to 1,000 files with each asset up to 5 MiB), Workers KV (create, list, rename, delete namespaces; put, get, list, delete keys; bulk operations), D1 (one database with up to 100 MB per database and 100 MB total), Durable Objects (deploy Workers with Durable Object bindings and migrations), Hyperdrive (up to two database configurations and 10 connections), Queues (up to 10 queues), and mTLS/CA certificates (wrangler cert upload, list, delete operations).
Temporary account provisioning rate limits and restrictions
Cloudflare rate limits temporary account creation; wait before retrying or authenticate with a permanent account. The --temporary flag supports unauthenticated use only; existing OAuth, API token, or global API key credentials cause an error. --temporary is not a global flag; only commands that support temporary credentials include it. Temporary account provisioning is available only through the default public API endpoint and unavailable through the FedRAMP High API endpoint. Cloudflare may reject requests that fail additional abuse-prevention checks.
Concurrent subrequest limit per incoming request
Each incoming request to a Worker can make up to 6 concurrent outgoing fetch() requests. Fetches after the sixth will be delayed until previous fetches have finished. A Worker can still make up to 50 total subrequests per incoming request; the new limit applies only to concurrent execution.
Automatic deadlock avoidance for concurrent subrequests
The Workers Runtime automatically detects if delaying a fetch would cause deadlock and prevents it by cancelling the least-recently-used request. A fetch is not considered complete until the response body is fully consumed.
Durable Object subrequest limit increase
As of 2021-07-16, Workers can make up to 1000 subrequests to Durable Objects from within a single request invocation, up from prior limit of 50.
Cron trigger wall time limit
As of 2021-04-19, Cron Triggers have a 15 minute wall time limit in addition to the existing CPU time limit. Previously there was no limit, so cron triggers spending all time waiting for I/O could hang forever.
Durable Object 50GB default storage limit
As of 2022-02-25, Durable Objects users may store up to 50 GB of data by default; contact Cloudflare for increases.
Cache API total put limit
As of 2019-12-06, the total per-request Cache.put() limit is 5 GiB.
Durable Object transaction key change limit
As of 2020-11-05, the maximum number of Durable Objects keys that can be changed in a single transaction is 128.
Durable Object CPU time limit enforcement
As of 2021-04-23, CPU time limits are enforced at the object level rather than request level. Each new request tops up the time limit to 500ms. After the beta period, this increases to 30 seconds.
KV operations per-request limit error message
As of 2020-12-04, improved error message when a single request performs more than 1000 KV operations to clarify that a per-request limit was reached, not a global rate limit.
Individual Cache.put limit
As of 2019-12-06, individual Cache.put() limits are the lesser of 5 GiB or the zone's normal cache limits.
Service bindings connection limit note
The runtime measures simultaneous open connections from the top-level request. Workers triggered via Service bindings share the same connection limit.
Account plan limits table
Workers Free plan: 100,000 requests per day, 10 ms CPU time, 128 MB memory, 50 subrequests per request, 6 simultaneous outgoing connections per request, 64 environment variables per Worker, 5 KB environment variable size, 3 MB Worker size (after compression), 1 second startup time, 100 Workers per account, 5 Cron Triggers per account, 20,000 Static Asset files per Worker version, 25 MiB individual Static Asset file size. Workers Paid plan: no request limit, 5 min CPU time (default 30 seconds), 128 MB memory, 10,000 subrequests per request (up to 10M), 6 simultaneous outgoing connections per request, 128 environment variables per Worker, 5 KB environment variable size, 10 MB Worker size (after compression), 1 second startup time, 500 Workers per account, 250 Cron Triggers per account, 100,000 Static Asset files per Worker version, 25 MiB individual Static Asset file size.
Request and response size limits
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 depends on Cloudflare account plan (not Workers plan): Free plan 100 MB, Pro plan 100 MB, Business plan 200 MB, Enterprise plan 500 MB by default (can be increased by contacting Cloudflare Support).
CPU time definition and limits
CPU time measures how long the CPU spends executing Worker code. Waiting on network requests such as fetch() calls, KV reads, or database queries does not count toward CPU time. CPU time per HTTP request: Workers Free 10 ms, Workers Paid 5 min (default 30 seconds). CPU time per Cron Trigger: Workers Free 10 ms, Workers Paid 30 seconds for intervals < 1 hour, 15 min for intervals >= 1 hour. Average Worker uses approximately 2.2 ms per request. Heavier workloads handling authentication, server-side rendering, or parsing large payloads typically use 10-20 ms.
CPU time limit error 1102
When a Worker exceeds its CPU time limit, Cloudflare returns Error 1102 to the client with 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.
Resolving CPU time limit errors
To resolve a CPU time limit error: (1) Increase the CPU time limit — On Workers Paid plan, raise the limit from default 30 seconds up to 5 minutes (300,000 ms) using the limits configuration in Wrangler or in the dashboard. (2) Optimize your code — Use CPU profiling with DevTools to identify CPU-intensive sections. (3) Offload work — Move expensive computation to Durable Objects or process data in smaller chunks across multiple requests.
Memory limit per isolate
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.
Memory limit error 1102
When a Worker exceeds its memory limit, Cloudflare returns Error 1102 to the client with 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.
Resolving memory limit errors
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.
Duration limits by trigger type
Duration measures wall-clock time from start to end of a Worker invocation. HTTP request: no limit. Cron Trigger: 15 min. Durable Object Alarm: 15 min. Queue Consumer: 15 min.
Duration and waitUntil behavior
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.
Daily request limit for Workers Free plan
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. Routes can be configured to fail open (bypass the Worker, requests behave as if no Worker is configured) or fail closed (return Cloudflare 1027 error page, use this for security-critical Workers).
Subrequests limits
A subrequest is any request a Worker makes using the Fetch API or to Cloudflare services like R2, KV, or D1. Subrequests per invocation: Workers Free 50, Workers Paid 10,000 (up to 10M). Subrequests to internal services: Workers Free 1,000, Workers Paid 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.