Skip to main content
Transform your testing process with: Real Device Features, Company-wide Licences, & Test Observability

Queue tests on BrowserStack Automate

Queue your tests over and above your parallel limit for running concurrent tests

You can run multiple tests in parallel to speed up your builds, if you have not already done so.

Your Automate plan supports running the number of parallel tests that you have purchased (5 during free trial). But with test queueing, you can send more parallel test requests to BrowserStack than your plan limit.

The following are the salient points for queueing your tests:

  1. You can launch an additional number of parallel tests with different browser configurations above your parallel limit that you have purchased.
  2. The additional tests will be queued and they would run as and when your existing running tests complete their execution.
  3. For instance, if you want to run 5 additional tests, apart from your subscribed limit of, say, 2 parallel tests, we will queue the additional 5 tests until one of the 2 initial tests finish, and a slot is available for execution.
  4. With queuing, you don’t need to worry about managing your test pipeline - we automatically take care of scheduling and execution for you.

With this feature, BrowserStack accounts with 1-5 parallels, can queue 5 tests. And, accounts with more than 5 parallels will have a max queue length equal to the number of parallels.

For example, if you have 2 parallel tests for your account, you can queue up to 5 more tests, but if you have 200 parallel tests, you can queue up to 200 more tests.

The wait limit for the execution of a queued test is 15 minutes after which the queued tests will be dropped.

Use the same BrowserStack user credentials to send a Plan API request and to trigger your tests so that you can plan parallels efficiently.

Scenarios where queuing helps

Queuing is enabled by default by BrowserStack to ensure you don’t have to worry about managing the test execution on your end. This helps especially in the following scenarios:

  • When you have multiple projects / PRs to test using the same BrowserStack account. If the other project is already running at full capacity, your new tests are better off in a queue than getting discarded altogether.
  • When you have multiple users in your team who use the same BrowserStack account for their projects. Rationing of parallel tests across teams can be inefficient - instead, queuing can help you manage the test executions in a simpler way.
  • If the number of total test cases is within the queue limit and if you don’t want to write some logic to dispatch tests, you can just submit all your tests to BrowserStack, and we will automatically manage the test runs for you.

In a few rare cases, BrowserStack will automatically put your tests in a queue for a short period of time so your other tests can run first. This is usually done when the device, browser & OS configurations you want to run your test on has a long start-time delay (either because of peak usage or booting up time). This makes way for the next test which can be quickly run - thus reducing the overall time taken to run your tests. The previously queued test will be automatically dequeued and run whenever a slot becomes available.

How test queuing works

Queues are managed at a user level and not at an organization level. This approach grants the allotted queues to each user in the organization, thus letting tests be added to the queue when all parallels are in use.

To understand the issue with managing queues at an organization level, consider this example, where a user1 in an organization uses all allocated 5 parallels and 5 queues. Whenever user1 polls the Plan API using their BrowserStack credentials, both the parallel and queues will always appear occupied. As the queue always appears occupied, user2 loses an opportunity to push their tests in the queue.

BrowserStack allocates the queues, which is 5 in this example, at a user level to avoid this issue. Both user1 and user2 are allocated 5 queues each. When user2 polls the Plan API, the response shows how many of their queue count the user consumed. This approach allows user2 to queue their tests irrespective of whether all parallels are in use or not.


You can also choose to manage the dispatching of tests at your end with/without utilizing the queueing functionality. You can use the Plan API to find out the parallel sessions running, the max allowed sessions, queued sessions and max allowed queued sessions for your plan and dispatch tests accordingly.

We're sorry to hear that. Please share your feedback so we can do better

Contact our Support team for immediate help while we work on improving our docs.

We're continuously improving our docs. We'd love to know what you liked

Thank you for your valuable feedback

Is this page helping you?


We're sorry to hear that. Please share your feedback so we can do better

Contact our Support team for immediate help while we work on improving our docs.

We're continuously improving our docs. We'd love to know what you liked

Thank you for your valuable feedback!

Talk to an Expert
Download Copy