Concurrency & Rate Limits

Browser automation becomes powerful when you can run multiple browser sessions simultaneously. Whether you’re scraping data at scale, running parallel tests, or serving multiple users, understanding concurrency and rate limits is critical.

Each browser session requires dedicated resources and has a minimum runtime of one minute. To ensure system stability and fair resource allocation, two key limits apply:

• Session Concurrency: The maximum number of browser sessions that can run simultaneously on your account

• Rate Limiting: The maximum number of new browser sessions you can create per minute

These limits depends on your plan:

​

Reaching Limits

When reaching the session concurrency limit of your plan, any subsequent request to create a new session will return an HTTP 429 Too Many Requests error. That means the request was effectively dropped.

To check the status of your rate limit, you can look at the headers of the response:

• x-ratelimit-limit - How many requests you can make.

• x-ratelimit-remaining - How many requests remain in the time window.

• x-ratelimit-reset - How many seconds must pass before the rate limit resets.

• retry-after - If the max has been reached, this is the number of seconds you must wait before you can make another request. This is documented here.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
x-ratelimit-limit: 3
x-ratelimit-remaining: 0
x-ratelimit-reset: 45
retry-after: 45

​

Avoiding Rate Limits

To avoid rate limits, you can either run fewer concurrent sessions or close sessions explicitly as opposed to letting them time out.

For example, if you have a Hobby plan with a limit of 3 concurrent sessions, you can create up to 3 sessions in a 60 second window. If you try to create a 4th session within that window, it will be rate limited and return an HTTP 429 error.

If you need more concurrency, you can upgrade to a plan that allows for a higher limits. See Plans & Pricing for more details.