Why Aren’t Your Playwright Projects Running in Parallel?

If you’e ever set fullyParallel:true in your Playwright config and expected your Chrome and Safari projects to run simultaneously, only to watch them execute one after another,you're not alone. This is one of the most common points of confusion when teams scale their Playwright test suites.

Let’s clear up how Playwright actually handles parallelism and what you can do to optimize your test execution time.

How Playwright Schedules Work

When you run Playwright tests with multiple projects, here’s what actually happens: Playwright creates a queue of all test tasks across all projects. Each task represents a single test file running in a specific project configuration. If you have 10 test files and 2 projects (Chrome and Mobile Safari), that’s 20 tasks total.

With --workers=4, Playwright spawns four worker processes. These workers pull tasks from the queue and execute them. Here's the key insight: Playwright doesn't guarantee that tasks from different projects will run simultaneously. It simply assigns the next available task to the next available worker.

In practice, this often means one project finishes before another starts, especially if your test files are roughly the same size. The scheduler optimizes for worker utilization, not project distribution.

Understanding fullyParallel

The fullyParallel: true setting is frequently misunderstood. It doesn't mean "run all projects in parallel." Instead, it controls how tests within each file are executed.

By default, Playwright runs test files in parallel but tests within a single file sequentially. When you enable fullyParallel: true, even tests in the same file run in parallel. This creates more tasks in the queue, giving the scheduler more flexibility to distribute work.

Here’s a concrete example: You have a file with 5 tests and 2 projects.

• Without fullyParallel: 2 tasks (one per project), each running 5 tests sequentially
• With fullyParallel: 10 tasks (5 tests × 2 projects), all competing for workers

The second approach can actually help projects interleave because there are more granular tasks to distribute.

The Worker Count Reality

Increasing workers doesn’t automatically make projects run in parallel. If you have 10 test files, 2 projects, and 4 workers, you might think “perfect, 2 workers per project.” But Playwright doesn’t think that way.

The scheduler assigns work dynamically. If Chrome’s tests finish faster, all 4 workers might end up handling Safari tests toward the end. The goal is to keep workers busy, not to balance projects.

When to increase workers:

• You have more test files than your current worker count
• Your workers are sitting idle (check CPU usage during test runs)
• Your machine has available CPU cores (a good rule: workers ≤ CPU cores)

When NOT to increase workers:

• Tests are I/O bound (waiting for network, animations)
• Your machine is already maxed out
• You have only a few test files

Real Strategies for Multi-Browser Testing

If you genuinely need Chrome and Safari tests to run simultaneously, perhaps because each takes 30 minutes and you want results in 30 minutes, not 60 , here are your options:

1. Run separate Playwright commands in parallel

bash
npx playwright test --project=chromium & \
npx playwright test --project=safari &
wait

This spawns independent Playwright processes, each with its own worker pool. It’s simple but uses more system resources.

2. Increase workers significantly If you have 10 test files per project, us --workers=20 or more. This gives the scheduler enough workers to naturally distribute tasks across projects. Monitor your system, this only works if you have the CPU and memory headroom.

3. Use sharding across CI machines Split your test suite across multiple machines, with each running a subset of projects. This is how most teams handle large multi-browser suites in production:

bash
# Machine 1
npx playwright test --project=chromium
# Machine 2  
npx playwright test --project=safari
The Bottom Line

Playwright’s scheduler prioritizes keeping workers utilized over balancing projects. This is usually the right choice, it minimizes total execution time when you care about “when do all tests finish?” rather than “when does each project finish?”

For most teams, the solution isn’t forcing project parallelism but optimizing worker count and understanding the scheduler’s behavior. If true simultaneous project execution is critical, separate Playwright processes or CI sharding are your best bets.

The confusion around this topic is understandable , the term “parallel” appears in multiple contexts with different meanings. Once you grasp how the task queue and workers interact, you can make informed decisions about structuring your test runs.

Want more insights like this? Visit and subscribe to TestDino Insights for practical Playwright tips, testing strategies, and solutions to common challenges faced by QA teams.