Run Robot Framework Tests in Parallel

Use Pabot, Robot Framework’s documented parallel test runner. Install it with pip install -U robotframework-pabot. By default, Pabot distributes suite files across worker processes; test cases inside each suite still run sequentially. To run test cases from one suite in parallel, add --testlevelsplit:

pabot --testlevelsplit --processes 8 tests

Choose the worker count for your machine and test workload. Parallel execution can reduce elapsed time when tests are independent, but it can also repeat suite setup and expose conflicts over shared accounts, files, or environments.

1. Install Pabot and choose a split mode

Pabot is distributed as the robotframework-pabot Python package. Install or upgrade it in the same Python environment where you run Robot Framework:

python -m pip install -U robotframework-pabot

Then choose the unit of work that should run concurrently:

Mode	Command	When to use it
Suite-level (default)	pabot --processes 4 tests	You have multiple suite files that can run independently. Cases inside a suite remain sequential.
Test-level	pabot --testlevelsplit --processes 4 tests	You want individual test cases, including cases from one suite, to run in separate processes.

Robot Framework’s regular runner is invoked as robot [options] data; it runs tests in a suite one by one. Pabot supplies the parallel execution mechanism. Robot’s test selection options such as --test, --suite, --include, and --exclude are documented in the Robot Framework User Guide.

2. Run suite files in parallel

With a directory of suites, the minimal command uses Pabot’s default suite-level split:

pabot tests

To set the worker count explicitly:

pabot --processes 4 tests

Each worker is a separate process. A suite is assigned as a unit, so test cases within that suite do not become parallel just because you increased the worker count. This mode is often a good starting point when the test directory already contains several independent suites.

3. Run cases from the same suite in parallel

For two or more cases in one .robot file, enable test-level splitting. For example, given tests/smoke.robot:

*** Test Cases ***
TC001
    Log    First independent test

TC002
    Log    Second independent test

Run the cases as separate work items with:

pabot --testlevelsplit --processes 2 tests/smoke.robot

Use --processes N to set the maximum worker capacity you want Pabot to use. Pabot documents its default as the maximum of two and the CPU count. That default is not a guarantee that the same number is appropriate for your workload or machine; begin with a modest value and adjust based on available CPU, memory, and the capacity of systems your tests call.

4. Account for setup, teardown, and shared state

Test-level splitting changes suite lifecycle behavior. Suite setup and suite teardown run for each parallel instance of the suite. Test setup and teardown continue to run for each test case. If suite initialization is expensive, or creates a shared environment that assumes one execution, this can add time or cause conflicts.

• Make suite setup safe to run more than once, or move work that must happen once to an appropriate external orchestration step.
• Give each parallel test a unique account, record, temporary directory, or other mutable resource where possible.
• Do not assume test execution order when tests run in separate processes.
• Ensure teardown only removes resources owned by that test or worker.

When tests must coordinate access to shared resources, PabotLib supports locking and resource distribution. Pabot documents --pabotlib for starting PabotLib and --resourcefile for providing a resource file used with it. Consult the official parallel execution guide for the required resource-file structure and exact options for your version.

5. Choose workers, chunks, or shards deliberately

These options address different constraints; they are not interchangeable:

Need	Option	What it does
Set local concurrency	--processes N	Sets the worker count for Pabot on the machine.
Coordinate shared resources	PabotLib, --pabotlib, --resourcefile	Provides locking and resource distribution for tests that need coordination.
Divide execution across machines	--shard i/n	Selects a shard of the work for distributed execution. Configure separate machines to run the intended shard indices.
Group work into a number of Robot runs	--chunk	Groups suites into a limited number of Robot runs, which can help share setup and teardown within a chunk.

Use sharding when the distribution boundary is multiple machines, not simply to increase local worker count. Consider chunking when setup and teardown costs dominate and grouping suites into fewer Robot runs fits your execution model. Check the official guide for the syntax supported by your installed Pabot release before adding less common options to a production command.

6. Troubleshoot common problems

Symptom	Likely cause	What to check or change
Cases in one file still appear sequential	Pabot uses suite-level splitting by default.	Add --testlevelsplit and confirm the cases are separate Robot test cases.
Suite setup or teardown runs more than once	Test-level splitting creates parallel instances of the suite.	Make suite lifecycle work repeatable, isolate per-worker state, or use an execution mode that groups the work appropriately.
Tests fail intermittently only in parallel	Workers may be changing the same account, file, database row, or environment.	Isolate test data or coordinate access with PabotLib locking and resource distribution.
More workers make runs slower or unstable	The workload or machine may not have capacity for that concurrency; downstream services may also be constrained.	Lower --processes, then increase gradually while observing run duration and failures.
Pabot command is not found	Pabot may have been installed into a different Python environment.	Activate the intended environment and install with python -m pip install -U robotframework-pabot.
Shards omit or repeat work	Machines may be using the wrong shard index or inconsistent shard counts and inputs.	Verify the i/n assignment across machines and keep the test inputs consistent.

7. Performance, reliability, and cost

Parallelism can reduce wall-clock time when there are enough independent suites or cases to keep workers busy. It does not make an individual test faster, and the gain is limited by the slowest work item, machine capacity, setup overhead, and any shared service bottlenecks. The official documentation gives a default process-count rule, not a universal optimal worker count or performance benchmark.

For a reliable rollout, first run the existing suite sequentially and establish that it passes. Then enable Pabot with a small worker count, inspect repeated setup behavior, and address shared-state conflicts before raising concurrency. Compare elapsed time and failure patterns for the same selection of tests. Pabot itself is installed as a Python package; infrastructure and any external test services remain part of your own execution cost.

Or skip the browser setup

If your Robot Framework checks need website screenshots, ScreenshotNeo provides a screenshot API and MCP server. Its API takes one GET request with a URL and returns an image or PDF. The API documentation covers the request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Can two test cases in one .robot file run at the same time?

Yes. Run Pabot with --testlevelsplit and set a suitable --processes value.

Does Robot Framework run tests in parallel by itself?

The standard Robot Framework runner executes tests within a suite sequentially. Pabot is the documented parallel runner.

Will parallel execution always be faster?

No. It depends on independent work, setup overhead, available capacity, and shared resource constraints. Measure with your own tests.