platform/limits

102 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Subrequest time limits and waitUntil

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.

Simultaneous open connections limit

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, connect() API for opening TCP socket. Outbound WebSocket connections also count toward this limit.

Simultaneous connections behavior

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.

Environment variables limits

Variables per Worker (secrets + text): Workers Free 64, Workers Paid 128. Variable size: Workers Free 5 KB, Workers Paid 5 KB. Variables per account: Workers Free no limit, Workers Paid no limit.

Worker size limits

After compression (gzip): Workers Free 3 MB, Workers Paid 10 MB. Before compression: Workers Free 64 MB, Workers Paid 64 MB. Larger Worker bundles can impact startup time.

Reducing Worker size strategies

To reduce Worker size: (1) Remove unnecessary dependencies and packages. (2) Store configuration files, static assets, and binary data in KV, R2, D1, or Workers Static Assets instead of bundling them. (3) Split functionality across multiple Workers using Service bindings.

Worker startup time limit

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.

Startup time limit error 10021

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.

Measuring and reducing startup time

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. Refer to wrangler check startup for more details.

Number of Workers per account

Workers Free plan: 100 Workers per account. Workers Paid plan: 500 Workers per account. If you need more than 500 Workers, consider using Workers for Platforms.

Routes and domains limits

Routes per zone: 1,000. Routes per zone (wrangler dev --remote): 50. Custom domains per zone: 100. Routed zones per Worker: 1,000.

Routes and domains limit exceptions

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

Maximum object size: Workers Free 512 MB, Workers Paid 512 MB. Calls per request: Workers Free 50, Workers Paid 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()).

Chunked response bodies and Cache API put() behavior

The size of chunked response bodies (Transfer-Encoding: chunked) is not known in advance. Calling .put() with such a response blocks subsequent .put() calls until the current one completes.

Log size limit

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.

Static Assets limits

Files per Worker version: Workers Free 20,000, Workers Paid 100,000. Individual file size: Workers Free 25 MiB, Workers Paid 25 MiB. _headers rules: Workers Free 100, Workers Paid 100. _headers characters per line: Workers Free 2,000, Workers Paid 2,000. _redirects static redirects: Workers Free 2,000, Workers Paid 2,000. _redirects dynamic redirects: Workers Free 100, Workers Paid 100. _redirects total: Workers Free 2,100, Workers Paid 2,100. _redirects characters per rule: Workers Free 1,000, Workers Paid 1,000. To use the increased file count limits in Wrangler, you must use version 4.34.0 or higher.

Bundled plan limits (deprecated)

Bundled plan Workers have no duration limits for Cron Triggers, Durable Object Alarms, or Queue Consumers. Bundled plan limits differ from Workers Paid: Subrequests 50/request, CPU time (HTTP requests) 50 ms, CPU time (Cron Triggers) 50 ms, Cache API calls/request 50. Unbound and Bundled plans have been deprecated and are no longer available for new accounts. If your Worker is on an Unbound plan, limits match the Workers Paid plan.

Workers Paid plan independence from other Cloudflare plans

Workers Paid plan is separate from any other Cloudflare plan (Free, Professional, Business) you may have. Enterprise customers should reach out to their account team to confirm pricing details.

Workers Paid plan minimum charge

The Workers Paid plan has a minimum charge of $5 USD per month for an account. The plan includes Workers, Pages Functions, Workers KV, Hyperdrive, and Durable Objects usage. There are no additional charges for data transfer (egress) or throughput (bandwidth).

Workers Standard usage model pricing table

The Workers Standard usage model has the following pricing structure: **Requests:** - Free plan: 100,000 per day - Standard plan: 10 million included per month, +$0.30 per additional million **Duration:** - Free plan: No charge for duration - Standard plan: No charge or limit for duration **CPU time:** - Free plan: 10 milliseconds of CPU time per invocation - Standard plan: 30 million CPU milliseconds included per month, +$0.02 per additional million CPU milliseconds. Max of 5 minutes of CPU time per invocation (default: 30 seconds). Max of 15 minutes of CPU time per Cron Trigger or Queue Consumer invocation.

Inbound requests billing exclusions

Inbound requests to your Worker are billed. However, Cloudflare does not bill for subrequests you make from your Worker. WebSocket connections made to a Worker are charged as a request, representing the initial Upgrade connection made to establish the WebSocket. WebSocket messages routed through a Worker do not count as requests. Requests to static assets are free and unlimited.

Workers pricing example 2: static assets with dynamic code

A project serving 15 million requests per month where 80% (12 million) serve static assets and 20% invoke dynamic Worker code with 7ms average CPU time per request would have the following estimated monthly costs: - Subscription: $5.00 - Requests to static assets: $0 - Requests to Worker: $0 - CPU time: $0 - Total: $5.00

Workers pricing example 3: Cron Trigger with high CPU time

A Worker running on a Cron Trigger once per hour (720 requests/month) with 3 minutes (180,000ms) of CPU time per request would have the following estimated monthly costs: - Subscription: $5.00 - Requests: $0.00 - CPU time: $1.99 (formula: ((180,000 ms * 720) - 30,000,000) / 1,000,000 * $0.02) - Total: $6.99

Workers pricing example 4: high traffic 100 million requests

A high traffic Worker serving 100 million requests per month with 7ms average CPU time per request would have the following estimated monthly costs: - Subscription: $5.00 - Requests: $27.00 (formula: (100,000,000 - 10,000,000) / 1,000,000 * $0.30) - CPU time: $13.40 (formula: ((7 ms * 100,000,000) - 30,000,000) / 1,000,000 * $0.02) - Total: $45.40

Workers pricing example 5: with 80% cache hit rate

A Worker serving 100 million requests per month with 7ms average CPU time per request and 80% cache hit rate (80 million from cache, 20 million invoking Worker) would have the following estimated monthly costs: - Subscription: $5.00 - Requests: $27.00 (all 100 million requests billed) - CPU time: $2.20 (formula: ((7 ms * 20,000,000) - 30,000,000) / 1,000,000 * $0.02) - Total: $34.20

Containers pricing structure

Containers are billed for every 10ms that they are actively running. Pricing with included monthly usage as part of the $5 USD per month Workers Paid plan: | | Memory | CPU | Disk | |------------------|-------------------------------------------------------------------------|------------------------------------------------------------------|----------------------------------------------------------------| | Free | N/A | N/A | N/A | | Workers Paid | 25 GiB-hours/month included, +$0.0000025 per additional GiB-second | 375 vCPU-minutes/month, +$0.000020 per additional vCPU-second | 200 GB-hours/month, +$0.00000007 per additional GB-second | Charges start when a request is sent to the container or when it is manually started. Charges stop after the container instance goes to sleep, which can happen automatically after a timeout.

Containers network egress pricing

Containers egress is priced at the following regional rates: | Region | Price per GB | Included Allotment per month | |------------------------|--------------|------------------------------| | North America & Europe | $0.025 | 1 TB | | Oceania, Korea, Taiwan | $0.05 | 500 GB | | Everywhere Else | $0.04 | 500 GB |

Service Bindings request billing

Requests made from your Worker to another worker via a Service Binding do not incur additional request fees. If Worker A makes a subrequest to Worker B via a Service Binding or calls an RPC method provided by Worker B via a Service Binding, this is billed as one request (for the initial invocation of Worker A) and the total amount of CPU time used across both Worker A and Worker B. This allows you to split apart functionality into multiple Workers without incurring additional costs.

Workers Free plan limits

By default, users have access to the Workers Free plan which includes limited usage of Workers, Pages Functions, Workers KV and Hyperdrive.

Service Bindings billing on deprecated pricing plans

If your Worker is on the deprecated Bundled or Unbound pricing plans, incoming requests from Service Bindings are charged the same as requests from the Internet. In a scenario where Worker A calls Worker B via Service Binding, you would be charged for two requests: one to Worker A and one to Worker B.

Pages Functions billing

All Pages Functions are billed as Workers. All pricing and inclusions in the Workers pricing document apply to Pages Functions.

Billable request definition

Only requests that hit a Worker will count against your limits and your bill. Since Cloudflare Workers runs before the Cloudflare cache, the caching of a request still incurs costs.

Static assets requests billing

Requests to static assets are free and unlimited. Requests to the Worker script are billed according to Workers pricing. There is no additional cost for storing assets.

run_worker_first free tier behavior

When using run_worker_first, requests matching the specified patterns will always invoke your Worker script. If you exceed your free tier request limits, these requests will receive a 429 (Too Many Requests) response instead of falling back to static asset serving. Negative patterns (patterns beginning with !/) will continue to serve assets correctly, as requests are directed to assets without invoking your Worker script.

Middleware in Workers charged as normal invocation

Middleware can be configured in Workers via the 'run_worker_first' option in the assets configuration, but is charged as a normal Worker invocation. Additional related options are being explored for future versions.

Static asset requests are free on Workers

Requests for static assets on Workers are free, just like on Cloudflare Pages. Pages Functions invocations are charged at the same rate as Workers, resulting in a similar cost structure between the two platforms.

Node.js version requirement for Prisma Postgres tutorial

Node.js v18.18 or higher is required to follow the Prisma Postgres with Cloudflare Workers tutorial.

Deployments limit - last 100 versions

You can only create a deployment with the last 100 uploaded versions of your Worker.

Gradual deployments limit uses last 100 uploaded versions

You can only create a gradual deployment with the last 100 uploaded versions of your Worker.

Rollback version history limit

You can only roll back to the 100 most recently published versions.

Preview URLs limitations

Preview URLs have the following limitations: (1) Not generated for Workers that implement a Durable Object. (2) Not currently generated for Workers for Platforms user Workers (temporary limitation). (3) Cannot be configured to run on a subdomain other than workers.dev. (4) Cannot currently view logs for Preview URLs, including Workers Logs, Wrangler tail, and Logpush.

Two versions per deployment limit

Workers currently only supports serving two different versions in one deployment. You can set the new version to 0% traffic to avoid normal traffic being routed to it, which is useful for smoke testing before gradual deployment.

Give your agent this brain