CPU Limits for Workers
Every worker invocation now has a CPU time budget based on your plan, with larger budgets for queues, timers, cron runs, and workflows. A runaway request is stopped with a clear 503 and an error in your deployment logs instead of slowing down other traffic.
A request stuck in an infinite loop, or rendering a huge page, used to keep running for as long as it liked, and it slowed other traffic down while it ran. CPU limits now give every invocation of a worker a CPU time budget based on your plan. Code that goes over its budget is stopped.
Limits per plan
Only time your JavaScript spends running counts. Waiting on fetch(), database queries, and other I/O doesn't.
| Invocation | Free | Pro | Enterprise |
|---|---|---|---|
| HTTP request | 1 s | 5 s | 30 s |
| Queue message | 5 s | 30 s | 60 s |
| Timer fire | 5 s | 30 s | 60 s |
| Cron run | 10 s | 60 s | 120 s |
| Workflow execution (all of its steps) | 15 s | 120 s | 300 s |
| Startup (top-level code) | 5 s | 5 s | 5 s |
Background jobs get larger budgets than requests, because nobody is waiting on them and they usually do batch work.
What happens at the limit
- An HTTP request is answered with
503 Worker exceeded its CPU time limit. - A queue message, timer fire, cron run, or workflow execution fails the same way an uncaught exception in your handler would. Queue messages are retried up to their attempt limit.
- Your deployment's logs show an error line with how much CPU time the invocation used.
Other requests to your deployment keep running normally. If a request regularly comes close to its limit, move the heavy part into a queue or a workflow step.
Self-hosted instances can change every limit with environment variables.