| pcx_content_type | configuration | ||
|---|---|---|---|
| title | Limits | ||
| description | Learn about the limits associated with Browser Rendering. | ||
| sidebar |
|
import { Render, Plan, Tabs, TabItem, DashButton } from "~/components";
Browser Rendering limits are based on your Cloudflare Workers plan.
For pricing information, refer to Browser Rendering pricing.
:::note[Need higher limits?] If you are on a Workers Free plan and you want to increase your limits, upgrade to a Workers Paid plan in the Workers plans page of the Cloudflare dashboard: :::
| Feature | Limit |
|---|---|
| Browser hours | 10 minutes per day |
| Concurrent browsers per account (Workers Bindings only) 1 | 3 per account |
| New browser instances (Workers Bindings only) | 3 per minute |
| Browser timeout | 60 seconds 2 |
| Total requests (REST API only) 3 | 6 per minute (1 every 10 seconds) |
:::note[Need higher limits?] If you are on a Workers Paid plan and you want to increase your limits beyond those listed here, Cloudflare will grant requests for higher limits on a case-by-case basis. :::
| Feature | Limit |
|---|---|
| Browser hours | No limit (See pricing) |
| Concurrent browsers per account (Workers Bindings only) 1 | 30 per account (See pricing) |
| New browser instances per minute (Workers Bindings only) | 30 per minute |
| Browser timeout | 60 seconds 2 |
| Total requests per min (REST API only) 3 | 180 per minute (3 per second) |
By default, a browser instance will time out after 60 seconds of inactivity. If you want to keep the browser open longer, you can use the keep_alive option, which allows you to extend the timeout to up to 10 minutes.
There is no fixed maximum lifetime for a browser session as long as it remains active. By default, Browser Rendering closes sessions after one minute of inactivity to prevent unintended usage. You can increase this inactivity timeout to up to 10 minutes.
If you need sessions to remain open longer, keep them active by sending a command at least once within your configured inactivity window (for example, every 10 minutes). Sessions also close when Browser Rendering rolls out a new release.
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 the daily limit or seeing higher usage than expected, the most common cause is browser sessions that are not being closed properly. When a browser session is not explicitly closed with browser.close(), it remains open and continues to consume browser time until it times out (60 seconds by default, or up to 10 minutes if you use the keep_alive option).
To minimize usage:
- Always call
browser.close()when you are finished with a browser session. - Wrap your browser code in a
try/finallyblock to ensurebrowser.close()is called even if an error occurs. - Use
puppeteer.history()orplaywright.history()to review recent sessions and identify any that closed due toBrowserIdleinstead ofNormalClosure. Sessions that close due to idle timeout indicate the browser was not closed explicitly.
You can monitor your usage and view session close reasons in the Cloudflare dashboard on the Browser Rendering page:
Refer to Browser close reasons for more information.
Rate limits are enforced with a fixed per-second fill rate, not as a burst allowance. This means you cannot send all your requests at once — the API expects them to be spread evenly over the minute.
| Plan | Rate limit | Per-second equivalent |
|---|---|---|
| Workers Free | 6 requests/min | 1 request every 10 seconds |
| Workers Paid | 180 requests/min | 3 requests/second |
If you exceed the rate limit, the API responds with HTTP status code 429 Rate limit exceeded. and includes a Retry-After header specifying how many seconds to wait before retrying.
When you make too many requests in a short period of time, Browser Rendering will respond with HTTP status code 429 Rate limit exceeded. You can view your account's rate limits in the Workers Free and Workers Paid sections above.
The example below demonstrates how to handle rate limiting gracefully by reading the Retry-After value and retrying the request after that delay.
const response = await fetch('https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-rendering/content', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer <your-token>',
},
body: JSON.stringify({ url: 'https://example.com' })
});
if (response.status === 429) {
const retryAfter = response.headers.get('Retry-After');
console.log(`Rate limited. Waiting ${retryAfter} seconds...`);
await new Promise(resolve => setTimeout(resolve, retryAfter \* 1000));
// Retry the request
const retryResponse = await fetch(/* same request as above */);
}
import puppeteer from "@cloudflare/puppeteer";
try {
const browser = await puppeteer.launch(env.MYBROWSER);
const page = await browser.newPage();
await page.goto("https://example.com");
const content = await page.content();
await browser.close();
} catch (error) {
if (error.status === 429) {
const retryAfter = error.headers.get("Retry-After");
console.log(
`Browser instance limit reached. Waiting ${retryAfter} seconds...`,
);
await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000));
// Retry launching browser
const browser = await puppeteer.launch(env.MYBROWSER);
}
}
Footnotes
-
Browsers close upon task completion or sixty seconds of inactivity (if you do not extend your browser timeout). Therefore, in practice, many workflows do not require a high number of concurrent browsers. ↩ ↩2
-
By default, a browser will time out after 60 seconds of inactivity. You can extend this to up to 10 minutes using the
keep_aliveoption. Callbrowser.close()to release the browser instance immediately. ↩ ↩2 -
Enforced with a fixed per-second fill rate, not as a burst allowance. This means you cannot send all your requests at once. The API expects them to be spread evenly over the minute. If you exceed the limit, refer to troubleshooting the
429 Too many requestserror. ↩ ↩2