Limits
Users on the Workers Free plan are limited to 10 minutes of browser rendering usage per day.
To increase this limit, you will need to upgrade to a Workers Paid plan.
Feature | Limit |
---|---|
Concurrent browsers per account (Workers Bindings only) | 3 per account |
New browser instances per minute (Workers Bindings only) | 3 per minute |
Browser timeout | 60 seconds |
Total requests per min (REST API only) | 6 per minute 1 |
Feature | Limit |
---|---|
Concurrent browsers per account (Workers Bindings only) | 10 per account 2 |
New browser instances per minute (Workers Bindings only) | 10 per minute 2 |
Browser timeout | 60 seconds |
Total requests per min (REST API only) | 60 per minute 1 2 |
While the limits above define the maximum number of concurrent browser sessions per account, in practice you may not need to hit these limits. Browser sessions close automatically—by default, after 60 seconds of inactivity or upon task completion—so if each session finishes its work before a new request comes in, the effective concurrency is lower. This means that most workflows do not require very high concurrent browser limits.
I upgraded from the Workers Free plan, but I'm still hitting the 10-minute per day limit. What should I do?
If you recently upgraded to the Workers Paid plan but still encounter the 10-minute per day limit, redeploy your Worker to ensure your usage is correctly associated with the new plan.
If you are hitting concurrency limits, or want to optimize concurrent browser usage with the Workers Binding method, here are a few tips:
- Optimize with tabs or shared browsers: Instead of launching a new browser for each task, consider opening multiple tabs or running multiple actions within the same browser instance.
- Reuse sessions: You can optimize your setup and decrease startup time by reusing sessions instead of launching a new browser every time. If you are concerned about maintaining test isolation (for example, for tests that depend on a clean environment) we recommend using incognito browser contexts ↗, which isolate cookies and cache with other sessions.
If you are still running into concurrency limits you can request a higher limit ↗.
-
Rate limits are enforced with a fixed per-second fill rate. For example, a limit of 60 requests per minute translates to 1 request per second. This means you cannot send all 60 requests at once; the API expects them to be spread evenly over the minute. If your account has a custom higher limit, it will also be enforced as a per-second rate. ↩ ↩2
-
Contact our team to request increases to this limit. ↩ ↩2 ↩3
Was this helpful?
- Resources
- API
- New to Cloudflare?
- Directory
- Sponsorships
- Open Source
- Support
- Help Center
- System Status
- Compliance
- GDPR
- Company
- cloudflare.com
- Our team
- Careers
- © 2025 Cloudflare, Inc.
- Privacy Policy
- Terms of Use
- Report Security Issues
- Trademark