Skip to main content
Limit the number of browser jobs running at once, queue excess work, and stop each session when its job finishes. Your account limit applies across all processes using the account.

​
Check available capacity

Example response for an account with a browser limit:
available is a snapshot. It does not reserve slots; another worker can start a browser before your next request. Set an application concurrency limit below the account cap if other jobs share the account, and handle parallel_browsers_limit_reached at startup. Browser slots are one of several account limits; limits covers request rates and proxy traffic quotas and the 429 codes each one returns.

​
Use an SDK pool

The Python and TypeScript SDKs provide map() and browser pools with a concurrency setting and managed cleanup. A pool can reuse a browser for several items. Cookies, storage, and open pages can carry over. Use separate sessions for jobs that need independent state, and retire a browser after a job that leaves it unusable. A persistent profile runs one browser at a time, so use a separate profile per account you run concurrently.

​
Stop sessions after failures

Put the stop call in finally, outside the framework connection block, so it also runs if connecting fails. The framework quickstarts show the full lifecycle. Choose an inactivity timeout long enough for legitimate pauses, but do not rely on it as your only cleanup. After a worker crashes, compare GET /profiles/active with the session IDs your application owns. Session age alone does not prove a leak: another worker may still be using that browser. Stop only sessions you can identify as abandoned.
POST /profiles/stop stops every browser on the account, including work owned by other processes. Use individual stop calls for routine cleanup.

​
Increase load gradually

Start with a small worker count. Measure completed jobs, target-site failures, proxy traffic, and browser startup errors before raising it. Browser slots and API rate limits are separate. Starting many browsers at once can hit a request limit even when slots remain. Queue startups and use bounded backoff with jitter for temporary capacity errors. See errors and retries. A start request can time out after the server has created the browser. Check active sessions before repeating a one-time start request.

​
What to monitor