Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsFor two Playwright Test suites on one machine, run npx playwright test --workers=2. Playwright Test uses worker processes and runs separate test files in parallel by default; tests in a single file run in order unless you enable parallel mode. If you mean two independent shell commands or Node.js programs, start them as separate operating-system processes instead. In either case, check that both jobs can safely use the same external accounts, records, files, and services.
First decide what “two scripts” means
Playwright Test is Playwright’s test runner. It discovers tests, assigns them to worker processes, and handles test setup and reporting. If your two scripts are test suites managed by Playwright Test, use its worker or parallel-test settings. If they are separate standalone programs, run two processes yourself. Those are different forms of concurrency: a worker limit controls Playwright Test’s workers, but it does not automatically coordinate unrelated programs launched elsewhere.
- Two test files: normally eligible to run at the same time; set the worker limit to two if that is your intended cap.
- Two groups of tests in one file: opt the tests into parallel mode.
- Two standalone Node.js programs or shell commands: launch each process separately.
- Two jobs on separate machines: use Playwright Test sharding in separate CI jobs.
Playwright’s official parallelism guide describes the worker model, defaults, configuration, and sharding behavior. It does not establish a general speed-up figure for running exactly two scripts: actual results depend on the machine, browsers, test design, and the system being tested.
Run two Playwright Test files with two workers
From the project directory, run:
npx playwright test --workers=2This tells Playwright Test to use at most two worker processes for that run. If the project has two eligible test files and enough work to schedule, the runner can execute work from both concurrently. Playwright does not promise that every run will keep both workers busy for its entire duration; discovery, dependencies, retries, test duration, and available work affect scheduling.
#1 Best Overall
The equivalent persistent setting is workers: 2 in the Playwright configuration. For example, if the project already has a playwright.config.ts, add the property to its existing configuration rather than replacing its projects, reporters, timeouts, or other settings:
import { defineConfig } from '@playwright/test';
export default defineConfig({
workers: 2,
});If the config already calls defineConfig, add workers: 2 to that object. A CLI option applies to that invocation; the config option is the default for runs that use the config. Keep the chosen limit aligned with the capacity available in local development or CI. Two browser workers can consume more CPU and memory than one.
Confirm that Playwright sees both suites
By default, Playwright Test runs test files in parallel, while tests within an individual file run in order in the same worker process. The two files must be discovered by the current project and test configuration. If only one file appears to run, check the configured test directory, file naming patterns, project selection, and whether a test-listing or grep option excluded one suite.
Two files being eligible for parallel execution does not mean that each test starts at precisely the same instant. The runner schedules tests across workers as work becomes available. The practical goal is overlapping execution, not synchronized start times.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallRun tests in one file concurrently
Tests in the same file run sequentially by default. To run tests in a particular group concurrently, configure that describe block:
import { test, expect } from '@playwright/test';
test.describe.configure({ mode: 'parallel' });
test('first independent check', async ({ page }) => {
await page.goto('https://example.com/');
await expect(page).toHaveTitle(/Example Domain/);
});
test('second independent check', async ({ page }) => {
await page.goto('https://example.com/');
await expect(page.locator('h1')).toHaveText('Example Domain');
});Replace the sample URL and assertions with checks for your application. Parallel mode makes the tests in the configured group eligible to run in separate worker processes. It is appropriate only when those tests are independent of one another’s order and shared external state.
Enable parallelism across the project
If the entire project is designed for test-level concurrency, set fullyParallel: true in the existing configuration:
import { defineConfig } from '@playwright/test';
export default defineConfig({
fullyParallel: true,
workers: 2,
});fullyParallel opts the project into parallel execution at test level, including tests that would otherwise stay together at file granularity. It does not itself specify a worker count; the workers setting or CLI option caps how many workers can run at once. Choose this project-wide setting only after reviewing shared state, ordering assumptions, setup, teardown, and any test fixtures that interact with external systems.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Run two standalone commands or Node programs
If the “scripts” are not test files managed by Playwright Test, start them as independent processes. For example, in a POSIX-compatible shell:
node scripts/first.mjs &
pid1=$!
node scripts/second.mjs &
pid2=$!
wait "$pid1"
status1=$?
wait "$pid2"
status2=$?
if [ "$status1" -ne 0 ] || [ "$status2" -ne 0 ]; then
exit 1
fiThis starts both processes in the background, waits for both to finish, and returns a failing exit status if either failed. Use the equivalent process or job controls for your shell or CI environment if it is not POSIX-compatible. In a CI system, two separate steps are not necessarily concurrent merely because they are separate steps; use parallel jobs or the CI system’s explicit concurrency feature when simultaneous execution is required.
Rank #3
Standalone processes do not share Playwright Test’s test discovery, worker scheduling, fixtures, or report handling. Also, --workers=2 only limits a Playwright Test run; it does not cap other processes started independently. If each standalone program launches its own browser or worker pool, account for all of those processes when estimating load.
Prevent races in shared data and resources
Each Playwright Test worker is an independent process, and each test receives an isolated browser context. That separates browser-level cookies and storage, but it does not isolate your application’s database, shared login account, filesystem, or third-party services. Two contexts can still edit the same server-side record at the same time.
Give each test its own data
Prefer unique records, users, filenames, and other mutable resources for each test. Playwright exposes test and worker information through its test APIs; use a test identifier or worker index when generating unique names. Clean up test-created data where appropriate. A unique browser context alone is not a solution if two tests write to the same account or database row.
Serialize only the constrained work
If a particular account, database resource, file, or service cannot tolerate overlapping changes, limit the affected project to one worker or use a named lock around the conflicting operation. A project-level worker limit can preserve parallelism in other projects while serializing the constrained one. The trade-off is lower concurrency for the work behind that limit; do not reduce all project concurrency if only one resource needs protection.
Locks must be shared by all processes that can touch the resource. A lock inside one test process will not protect against a separate script or another CI machine unless those participants use the same locking mechanism.
Scale beyond one machine with sharding
When one machine does not provide enough capacity, Playwright Test can split a suite into shards that run as separate CI jobs. For a two-shard run, invoke the test command in two jobs:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
npx playwright test --shard=1/2npx playwright test --shard=2/2Each shard is a fraction of the suite; neither command by itself runs both shards concurrently. Configure the CI workflow to start the two jobs at the same time and collect their results using the workflow’s reporting approach. Sharding is suitable for tests that can run in parallel. Without fullyParallel, distribution is generally at file granularity; with it, Playwright can balance work at test granularity.
Sharding adds operational work: CI must provision the jobs, make any required test data safe across machines, and preserve or combine results as needed. It increases available execution capacity only if the jobs actually run on separate available resources; it is not a guarantee that a suite will finish in half the time.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot concurrent runs
Only one test appears to run at a time
- Check that there are multiple discovered test files, or that the tests in one file use
test.describe.configure({ mode: 'parallel' })or project-widefullyParallel: true. - Confirm that the run is not constrained by a config or CLI worker limit of one.
- Check whether the project’s selected tests, dependencies, or other configuration leave only one runnable test available at a time.
Tests pass alone but fail together
- Look for shared accounts, records, files, ports, or other mutable resources.
- Make test data unique, clean it up safely, or serialize the resource that cannot be shared.
- Do not rely on an order between tests that run in parallel.
The machine becomes slow or unstable
Two workers are a concurrency cap, not a performance guarantee. Browser processes add resource use, and two active tests can also put more load on the application under test. Try a lower worker count, inspect the machine and service load, and increase concurrency only when both can handle it. If the goal is more total capacity rather than more load on one host, consider sharding across CI machines.
A shard runs only part of the suite
That is expected: --shard=1/2 and --shard=2/2 each select a portion. Ensure both commands are running as separate jobs, and check whether file-level balancing or test-level balancing is appropriate for your suite.
One standalone process fails but the other succeeds
Check each process’s exit status and logs independently. A shell that starts background jobs without waiting for them can finish before their results are known. Use explicit waits, as in the example above, or let the CI system track each parallel job’s status.
Or skip the browser setup
If your goal is to capture a website screenshot rather than run arbitrary Playwright assertions or workflows, ScreenshotNeo offers a one-request screenshot API. It is not a replacement for running Playwright Test suites, but it can remove the need to install and manage a browser for a screenshot task. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpScreenshotNeo accepts cookie or consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and responses identify the page verdict and billing status in headers. Its MCP server exposes screenshot tools for AI agents, including Claude, Cursor, and other MCP clients. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. These are ScreenshotNeo plan allowances and prices, not Playwright execution limits.
Learn about ScreenshotNeo, or sign up for 1,000 free screenshots a month with no card.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Frequently Asked Questions
Does Playwright Test require a separate plugin to use workers?
No additional parallelism plugin is needed for the worker behavior described here; it is part of Playwright Test.
Will test output always appear in the order the tests were written?
Not necessarily when tests run concurrently. Avoid using output order as evidence that one parallel test finished before another.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
