Run your whole suite at once
Threads decide how much of your suite runs in parallel — add lanes and the wall-clock time drops. When the fleet is busy, your session waits in a real line instead of failing your build.
Unlimited minutes on paid plans · no thread limit on free
Every lane you add is one more test running now, not next.
Your suite isn't slow. It runs one test at a time.
A suite that is “too slow to run on every commit” is usually not a test problem — it is a concurrency budget. Run the same tests side by side and the wall-clock time drops with every lane you add.
macOS 14
macOS 14
macOS 14
Win 11
Pixel 8
Galaxy S24
iPhone 15
iPad Pro
What you get
Threads = tests at once
One thread runs one test. Buy four and four run together; the fifth starts the moment one frees up.
Selenium, Appium, Playwright, Espresso and XCUITest
Every way in gets the same parallelism and the same fair queue. Bring the framework you already have.
Minutes are unlimited on paid plans
You buy how much runs at once, never total execution time. A long suite costs nothing extra to finish.
Free tier, no thread limit
Free accounts are capped by minutes, not concurrency — so you can measure your real runtime at full parallelism before buying anything.
- chromerunning now
- safarinext in line
- chromewaiting
- firefoxwaiting
Reclaims a device the moment one frees up.
Busy means wait, not a red build
When the fleet is full, a lot of infrastructure rejects your session and hands your suite a failure to deal with. Yours waits in a real line instead.
- You set the wait. Sessions wait up to your maxQueueWaitSeconds — default 180. Want a smoke test to fail fast instead? Set it to 0.
- Ranked per device. Every waiter takes a ticket, and you are only ever held behind someone waiting for the exact device you want. Two teams on different phones never block each other.
- Your suite keeps its device. A mobile suite reclaims the phone it just used, ahead of newer arrivals — so ten tests don't pay for ten clean-and-reacquire hand-offs.
Frequently asked questions
One thread is one test running at one time. Size it from the runtime you want rather than the size of your suite: a four-hour suite on one thread is roughly thirty minutes on eight. Then check your tests tolerate it — suites sharing an account or a fixture fail under concurrency in ways that look like flakiness and are not.
Your session waits in a queue rather than failing. You control the budget with maxQueueWaitSeconds, which defaults to 180 and is clamped between 0 and 600. Set it to 0 if you would rather fail fast than wait.
Up to twice your budget in the worst case. The wait has two phases — finding a device, then getting it ready — and each phase gets the full maxQueueWaitSeconds. So a default of 180 can mean up to six minutes of wall-clock wait before a session gives up. Plan the number around that.
A real line. Every waiting session takes a ticket, and a device is refused to you if another waiter outranks you for that specific device — affinity first, then oldest first. Ranking is per device rather than global, so a suite wanting any free Android is not blocked by someone waiting for a different model, and two customers wanting non-overlapping devices never wait on each other.
Because a phone takes about thirty seconds to clean between sessions, and several minutes when that escalates to a full reset. The old default of 60 was a browser-only number, and it meant a suite pinned to one device model saw test one pass and everything after it fail — on a fleet that was about to be free.
It can claim affinity for the device it was already using, and the queue honours that ahead of age. That matters more than it sounds: without it, a ten-test mobile suite pays for a clean and a re-acquisition between every test, which can triple the runtime on an identical fleet.
Some Appium and Selenium clients impose their own new-session timeout below our default, and give up before we do. That is a setting on your side and invisible to us, so if sessions fail earlier than your maxQueueWaitSeconds, check the client timeout first.
No. Free accounts are limited by minutes, and you can spend them across as many parallel threads as you like. That is deliberate, and it means you can measure your real suite runtime at real concurrency before deciding what to buy — which most free tiers in this category do not allow.
Parallel execution exposes test coupling. Suites that share an account, a fixture or a database row fail in ways that look like infrastructure flakiness the moment they run simultaneously — but that failure is in the suite, not the fleet, and adding threads makes it worse rather than better.
New sessions are refused rather than allowed — the system fails closed. It is deliberate and safer for your bill: if your concurrency entitlement cannot be verified, we would rather stop a session than run one you might not be entitled to.
Measure your real runtime before you buy anything
The free tier does not cap concurrency, so you can run your actual suite at actual parallelism and get a number instead of an estimate.