Products · Developer platform
Browser Run
Control and interact with headless browser instances programmatically
Pricing and limits
Pricing
As of Nov 3, 2026, from Cloudflare's docs, last updated there Apr 21, 2026. Licensed CC BY 4.0; navigation removed.
Available on Free and Paid plans
Billing depends on how you use Browser Run:
- Quick Actions: Charged for browser hours only.
- Browser Sessions (Puppeteer, Playwright, CDP): Direct browser control, charged for both browser hours and concurrent browsers.
Browser hours are shared across all methods.
| Workers Free | Workers Paid | |
|---|---|---|
| Browser hours | 10 minutes per day | 10 hours per month, then $0.09 per additional hour |
| Concurrent browsers (Browser Sessions only) | 3 browsers | 10 browsers (averaged monthly), then $2.00 per additional browser |
To view or change your plan, go to the Workers plans page in the Cloudflare dashboard:
Examples of Workers Paid pricing
Example: Quick Actions pricing
If a Workers Paid user uses Quick Actions for 50 hours during the month, the estimated cost for the month is as follows.
For browser hours:
50 hours - 10 hours (included in plan) = 40 hours
40 hours × $0.09 per hour = $3.60
Example: Browser Sessions pricing
If a Workers Paid plan user uses Browser Sessions (Puppeteer, Playwright, or CDP) for 50 hours during the month, and uses 10 concurrent browsers for the first 15 days and 20 concurrent browsers the last 15 days, the estimated cost for the month is as follows.
For browser hours:
50 hours - 10 hours (included in plan) = 40 hours
40 hours × $0.09 per hour = $3.60
For concurrent browsers:
((10 browsers × 15 days) + (20 browsers × 15 days)) = 450 total browsers used in month
450 browsers used in month ÷ 30 days in month = 15 browsers (averaged monthly)
15 browsers (averaged monthly) − 10 (included in plan) = 5 browsers
5 browsers × $2.00 per browser = $10.00
For browser hours and concurrent browsers:
$3.60 + $10.00 = $13.60
Pricing FAQ
How do I estimate my Browser Run costs?
You can monitor Browser Run usage in two ways:
To monitor your Browser Run usage in the Cloudflare dashboard, go to the Browser Run page. Go to Browser Run ↗
The
X-Browser-Ms-Usedheader, which is returned in every Quick Actions response, reports browser time used for the request (in milliseconds). You can also access this header using the Typescript SDK with the .asResponse() method:const contentRes = await client.browserRendering.content .create({ account_id: "account_id", }) .asResponse(); const browserMsUsed = parseInt( contentRes.headers.get("X-Browser-Ms-Used") || "", );
You can then use the tables above to estimate your costs based on your usage.
Do failed API calls, such as those that time out, add to billable browser hours?
No. If a Quick Actions request fails with a waitForTimeout error, the browser session is not charged.
How is the number of concurrent browsers calculated?
Cloudflare calculates concurrent browsers as the monthly average of your daily peak usage. In other words, we record the peak number of concurrent browsers each day and then average those values over the month. This approach reflects your typical traffic and ensures you are not disproportionately charged for brief spikes in browser concurrency.
How is billing time calculated?
At the end of each day, Cloudflare totals all of your browser usage for that day in seconds. At the end of each billing cycle, we add up all of the daily totals to find the monthly total of browser hours, rounded to the nearest whole hour. In other words, 1,800 seconds (30 minutes) or more is rounded up to the nearest hour, and 1,799 seconds or less is rounded down to the nearest whole hour.
For example, if you only use one minute of browser time in a day, that day counts as one minute. If you do that every day for a 30-day month, your total would be 30 minutes. For billing, we round that up to one browser hour.
Limits
As of Nov 3, 2026, from Cloudflare's docs, last updated there Oct 14, 2026. Licensed CC BY 4.0; navigation removed.
Browser Run limits are based on your Cloudflare Workers plan.
For pricing information, refer to Browser Run pricing.
Workers Free
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 (Browser Sessions only) 1 | 3 per account |
| New browser instances (Browser Sessions only) | 1 every 20 seconds |
| Browser timeout | 60 seconds 2 |
| Total requests (Quick Actions only) 3 | 1 every 10 seconds |
/crawl endpoint limits
The /crawl endpoint has additional limits for Workers Free plan users:
| Feature | Limit |
|---|---|
| Crawl jobs per day | 5 per day |
| Maximum pages per crawl | 100 pages |
Workers Paid
Need higher limits?
The limits below are defaults for Workers Paid users. If you need to scale beyond them, Cloudflare can increase your account limits. Request higher limits ↗︎.
| Feature | Limit |
|---|---|
| Browser hours | No limit (See pricing) |
| Concurrent browsers per account (Browser Sessions only) 1 | 200 per account (See pricing) |
| New browser instances per second (Browser Sessions only) | 3 per second |
| Browser timeout | 60 seconds 2 |
| Total requests per second (Quick Actions only) 3 | 30 per second |
FAQ
How can I manage concurrency and session isolation with Browser Run?
If you are hitting concurrency limits, or want to optimize concurrent browser usage, 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 ↗︎.
Can I increase the browser timeout?
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 20 minutes.
Is there a maximum session duration?
There is no fixed maximum lifetime for a browser session as long as it remains active. By default, Browser Run closes sessions after one minute of inactivity to prevent unintended usage. You can increase this inactivity timeout to up to 20 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 20 minutes). Sessions also close when Browser Run 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.
Why is my browser usage higher than expected?
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 20 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 Run page:
Refer to Browser close reasons for more information.
Troubleshooting
Error: 429 Too many requests
When you make too many requests in a short period of time, Browser Run will respond with HTTP status code 429 Too many requests. 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-run/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);
}
}
Error: 429 Browser time limit exceeded for today
This Error processing the request: Unable to create new browser: code: 429: message: Browser time limit exceeded for today error indicates you have hit the daily browser limit on the Workers Free plan. Workers Free plan accounts are limited to 10 minutes of Browser Run usage per day. If you exceed that limit, you will receive a 429 error until the next UTC day.
You can increase your limits by upgrading to a Workers Paid plan on the Workers plans page of the Cloudflare dashboard:
If you recently upgraded but still encounter the 10-minute per day limit, redeploy your Worker to ensure your usage is correctly associated with the new plan.
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 20 minutes using the
keep_aliveoption. Callbrowser.close()to release the browser instance immediately. ↩ ↩2 - If you exceed the per-second rate limit, you will receive a
429response. Refer to troubleshooting the429 Too many requestserror. ↩ ↩2
Timeline
October 2026
- Browser Run now runs Chrome 152
Browser Run now runs Chrome 152 by default. Your sessions get current web platform features, rendering fixes, and security patches. You do not need to change your code. This release also includes the following improvements: Updated default User-Agent. The default User-Agent for Quick Actions now reports Chrome 152 instead of Chrome 119. If you allowlist or match the Browser Run User-Agent, update…
- Agents SDK: Preview dev servers in the browser without public URLs
Agents that build websites need to check their work in a real browser. Internal hostnames let your agent's browser preview a dev server running in a container without exposing that server to the public Internet. With internal hostnames, the persistent browser in the Cloudflare Agents SDK can open sites that only your agent serves. Give the browser hostnames such as preview.internal, and its reque…
September 2026
- Connect multiple clients to one Browser Run session
Browser Run sessions now accept multiple concurrent connections. Before, a session accepted only one connection at a time, and other Workers had to wait until that connection closed. Now multiple Workers can connect to the same browser at the same time. Each puppeteer.connect() call opens its own Chrome DevTools Protocol (CDP) connection. Create a separate browser context for each request to keep…
- Browser Run adds WebMCP to Kitesurf and moves to document.modelContext
WebMCP now works in Kitesurf sessions as well as Lab sessions. Both backends use the document.modelContext API from the WebMCP Community Group draft ↗︎. Lab sessions no longer expose navigator.modelContextTesting. To list and run page tools: Chrome DevTools: Use the Application > WebMCP panel in the live view of a Lab session or in the Kitesurf playground ↗︎. AI agents: Start Chrome DevTools MCP…
- Subscribe to Browser Run crawl events
Browser Run crawl jobs can publish lifecycle events to Cloudflare Queues. Subscribe to started, updated, and finished events to track progress or trigger downstream processing without polling. To create an account-level subscription, run the following command: npmyarnpnpm npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished -…
- Browser Run adds session and DevTools methods to browser bindings
Browser Run browser bindings now provide typed methods for session management and DevTools operations. You can acquire a session, connect a browser client, create Live View URLs, manage targets, and close sessions without constructing HTTP requests. The new acquire() and launch() methods also accept outboundByHost. This lets you route requests for selected hostnames through another Worker, includ…
- Inspect logs, network requests, and DOM in Session Recordings
Browser Run Session Recordings now include an Inspect panel, giving you more context to understand what happened during a browser session without having to reproduce it. The Logs tab lets you search captured console output and filter messages by level. The Network tab shows each request's method, status, headers, payload, response, and timing waterfall, with the option to download the session's n…
- Control which hostnames Browser Run sessions can access
Browser Run now supports guardrails, which limit a browser session's HTTP and HTTPS requests to permitted hostnames. Use guardrails when you need to: Keep a browser workflow limited to a specific website and its subdomains. Load only known third-party APIs, scripts, images, and fonts. Generate a screenshot or PDF from HTML you provide while preventing it from loading external content. Set guardra…
August 2026
- Crawl endpoint now respects the Content Signals `use` directive
The /crawl endpoint now respects the use directive of the Content Signals ↗︎ standard, letting site owners express the maximum level at which their content may be used. You can declare your intended level with the new contentUse parameter. Allowed values, from least to most permissive, are reference and full, and the default is full. If a target site's robots.txt sets a use level that is more res…
- Run more headless browsers concurrently with Browser Run
Browser Run lets you automate headless browsers on Cloudflare's global network. Run full browser sessions for interactive workflows, or use Quick Actions for one-request tasks such as screenshots, PDFs, and capturing page content. If you are on the Workers Paid plan, your default limits are now higher: Limit Previous New Concurrent browsers 120 200 New browser instances / second 1 3 Quick Actions…
- Introducing Kitesurf, an agent-first browser on Browser Run
Kitesurf is Cloudflare's new stateless, highly scalable browser that runs entirely on top of Workers and is designed for AI agents. It is available for free while in beta. Compared to Chromium, Kitesurf uses 3–7× less CPU and memory for common agentic tasks like screenshots and HTML extraction, so you can run more sessions and scale better for bursty, AI-driven workloads. Your existing clients al…
July 2026
- Browser Run adds a Playground to the Cloudflare dashboard
Browser Run now includes a Playground in the Cloudflare dashboard. Use it to try Quick Actions against a live browser without creating a Worker, installing an SDK, or deploying code first. The Playground helps you test a target URL or raw HTML input, tune viewport and page-load settings, preview the output, and copy working code for the same request. With the Playground, you can: Capture visuals…
- Browser Run adds structured handoff for Human in the Loop
Browser Run now supports structured handoff for Human in the Loop workflows. Using Cloudflare-specific CDP commands, your agent can signal that it needs help, a human steps in through Live View to handle the task, and the agent resumes once the work is done. For agents running multi-step browser workflows, a single login wall or unexpected prompt can fail the entire run. Previously, scripts had t…
- New Browser Run endpoint for accessibility trees
Browser Run now supports a standalone /accessibilityTree endpoint, giving agent and automation workflows direct access to the browser's accessibility tree for a rendered webpage. An accessibility tree is the browser's structured view of a rendered page: roles, names, states, values, and hierarchy. It is useful for accessibility tooling, but also for AI agents and automation workflows that need pa…
June 2026
- New formats parameter for the Browser Run /snapshot endpoint
Browser Run's /snapshot endpoint now supports a formats parameter that lets you return multiple page formats in a single API call. Previously, /snapshot returned only HTML content and a screenshot. You can now also include Markdown and the accessibility tree in the same response. These formats are particularly useful for AI agent workflows: Markdown provides a token-efficient representation of pa…
May 2026
- Use Browser Run Quick Actions directly from Workers
You can now call Browser Run Quick Actions directly from a Cloudflare Worker using the quickAction() method on the browser binding. This simplifies how Workers interact with Browser Run by removing the need for API tokens or external HTTP requests. Your Worker communicates with Browser Run directly over Cloudflare's network, resulting in simpler code and lower latency. With the quickAction() meth…
April 2026
- Browser Rendering is now Browser Run
We are renaming Browser Rendering to Browser Run. The name Browser Rendering never fully captured what the product does. Browser Run lets you run full browser sessions on Cloudflare's global network, drive them with code or AI, record and replay sessions, crawl pages for content, debug in real time, and let humans intervene when your agent needs help. Along with the rename, we have increased limi…
- Browser Run adds Live View, Human in the Loop, and Session Recordings
When browser automation fails or behaves unexpectedly, it can be hard to understand what happened. We are shipping three new features in Browser Run (formerly Browser Rendering) to help: Live View for real-time visibility Human in the Loop for human intervention Session Recordings for replaying sessions after they end Live View Live View lets you see what your agent is doing in real time. The pag…
- Browser Run adds WebMCP support
Browser Run (formerly Browser Rendering) now supports WebMCP ↗︎ (Web Model Context Protocol), a new browser API from the Google Chrome team. The Internet was built for humans, so navigating as an AI agent today is unreliable. WebMCP lets websites expose structured tools for AI agents to discover and call directly. Instead of slow screenshot-analyze-click loops, agents can call website functions l…
- Manage Browser Rendering sessions with Wrangler CLI
Browser Rendering now supports wrangler browser commands, letting you create, manage, and view browser sessions directly from your terminal, streamlining your workflow. Since Wrangler handles authentication, you do not need to pass API tokens in your commands. The following commands are available: Command Description wrangler browser create Create a new browser session wrangler browser close Clos…
- Browser Rendering adds Chrome DevTools Protocol (CDP) and MCP client support
Browser Rendering now exposes the Chrome DevTools Protocol (CDP), the low-level protocol that powers browser automation. The growing ecosystem of CDP-based agent tools, along with existing CDP automation scripts, can now use Browser Rendering directly. Any CDP-compatible client, including Puppeteer and Playwright, can connect from any environment, whether that is Cloudflare Workers, your local ma…
March 2026
- Crawl entire websites with a single API call using Browser Rendering
Edit: this post has been edited to clarify crawling behavior with respect to site guidance. You can now crawl an entire website with a single API call using Browser Rendering's new /crawl endpoint, available in open beta. Submit a starting URL, and pages are automatically discovered, rendered in a headless browser, and returned in multiple formats, including HTML, Markdown, and structured JSON. T…
- Browser Rendering: 3x higher REST API request rate
Browser Rendering REST API rate limits for Workers Paid plans have been increased from 3 requests per second (180/min) to 10 requests per second (600/min). No action is needed to benefit from the higher limit. The REST API lets you perform common browser tasks with a single API call, and you can now do it at a higher rate. /content - Fetch HTML /screenshot - Capture screenshot /pdf - Render PDF /…
October 2025
- Workers WebSocket message size limit increased from 1 MiB to 32 MiB
Workers, including those using Durable Objects and Browser Rendering, may now process WebSocket messages up to 32 MiB in size. Previously, this limit was 1 MiB. This change allows Workers to handle use cases requiring large message sizes, such as processing Chrome Devtools Protocol messages. For more information, please see the Durable Objects startup limits.
September 2025
- Browser Rendering Playwright GA, Stagehand support (Beta), and higher limits
We’re shipping three updates to Browser Rendering: Playwright support is now Generally Available and synced with Playwright v1.55 ↗︎, giving you a stable foundation for critical automation and AI-agent workflows. We’re also adding Stagehand support (Beta) so you can combine code with natural language instructions to build more resilient automations. Finally, we’ve tripled limits for paid plans ac…
July 2025
- Introducing pricing for the Browser Rendering API — $0.09 per browser hour
We’ve launched pricing for Browser Rendering, including a free tier and a pay-as-you-go model that scales with your needs. Starting August 20, 2025, Cloudflare will begin billing for Browser Rendering. There are two ways to use Browser Rendering. Depending on the method you use, here’s how billing will work: REST API: Charged for Duration only ($/browser hour) Browser Sessions: Charged for both D…
- Browser Rendering now supports local development
You can now run your Browser Rendering locally using npx wrangler dev, which spins up a browser directly on your machine before deploying to Cloudflare's global network. By running tests locally, you can quickly develop, debug, and test changes without needing to deploy or worry about usage costs. Get started with this example guide that shows how to use Cloudflare's fork of Puppeteer (you can al…
May 2025
- Playwright MCP server is now compatible with Browser Rendering
We're excited to share that you can now use the Playwright MCP ↗︎ server with Browser Rendering. Once you deploy the server, you can use any MCP client with it to interact with Browser Rendering. This allows you to run AI models that can automate browser tasks, such as taking screenshots, filling out forms, or scraping data. Playwright MCP is available as an npm package at @cloudflare/playwright-…
April 2025
- Browser Rendering REST API is Generally Available, with new endpoints and a free tier
We’re excited to announce Browser Rendering is now available on the Workers Free plan ↗︎, making it even easier to prototype and experiment with web search and headless browser use-cases when building applications on Workers. The Browser Rendering REST API is now Generally Available, allowing you to control browser instances from outside of Workers applications. We've added three new endpoints to…
- Playwright for Browser Rendering now available
We're excited to share that you can now use Playwright's browser automation capabilities ↗︎ from Cloudflare Workers. Playwright ↗︎ is an open-source package developed by Microsoft that can do browser automation tasks; it's commonly used to write software tests, debug applications, create screenshots, and crawl pages. Like Puppeteer, we forked ↗︎ Playwright and modified it to be compatible with Cl…
February 2025
- New REST API is in open beta!
We've released a new REST API for Browser Rendering in open beta, making interacting with browsers easier than ever. This new API provides endpoints for common browser actions, with more to be added in the future. With the REST API you can: Capture screenshots – Use /screenshot to take a screenshot of a webpage from provided URL or HTML. Generate PDFs – Use /pdf to convert web pages into PDFs. Ex…
January 2025
- Increased Browser Rendering limits!
Browser Rendering now supports 10 concurrent browser instances per account and 10 new instances per minute, up from the previous limits of 2. This allows you to launch more browser tasks from Cloudflare Workers. To manage concurrent browser sessions, you can use Queues or Workflows: index.jsjsexport default { async queue(batch, env) { for (const message of batch.messages) { const browser = await…