An individual Worker script may consume up to:
Note that the time quotas are per request, while the memory quota is per worker instance. Cloudflare runs worker instances on many machines in many regions, automatically scaling them as necessary.
If an individual request exceeds one of the time quotas, that request will be canceled, but the script will be allowed to continue serving requests. If the memory quota is exceeded at any time, the script will be evicted from memory and all requests it was servicing will be canceled, but the worker will be automatically restarted to serve the next request that comes in.
Most worker requests consume less than a single millisecond. It’s rare for us to find a Worker script which is operating as intended and runs into the CPU time limit.
Here is the Worker CPU time limit based on Cloudflare Plan:
In general the 5ms offered to free plans is sufficient for all practical use-cases, including application hosting. If you have a usage which violates these limits, please reach out and we will be happy to discuss other options.
A worker must make all of its subrequests within the first fifteen seconds of its execution.
The 15 second clock time limit is a soft limit. After that period no new subrequests may be made from the script, but any pending subrequests will be allowed to complete. Long streaming responses will work as you expect.
We run at most one worker instance on each of the many servers we run at our edge locations around the world. Each instance can consume up to 128MB of memory. By using global variables you can persist data between requests on an individual node, but note that nodes are occasionally evicted from memory.
If you are concerned about memory usage, the solution is often to stream your responses (potentially using the TransformStream API) rather than loading an entire response into memory.
Your worker automatically scales onto thousands of servers around the world; there is no general limit to the number of requests per second Workers can handle.
Cloudflare does impose a number of abuse protection methods which are designed not to affect well-intentioned traffic. If you send many thousands of requests per second from a small number of client IP addresses, you can inadvertently trigger some of the protection methods. If you receive 1015 errors in response to traffic you believe should be allowed, please contact us to have the limits adjusted.
If you have an application which you expect to exceed these limits, feel free to contact us to have them raised.