CI/CD for Cypress and Playwright at Scale
Hundreds of browser tests are slow, flaky, and expensive - and they gate every merge.
End-to-end suites with Cypress or Playwright are the slowest and flakiest part of CI. Sharding helps speed, but flakiness and cost still bite.
Shard across runners
Split specs across a matrix of runners so a 30-minute suite finishes in a few minutes of wall-clock time.
Flakiness is the tax
Browser tests fail intermittently on timing and resource contention. Self-healing auto-retries the transient ones instead of failing the build.
No queue for big matrices
A wide shard matrix needs many runners at once. Warm pools start them all immediately instead of queueing behind GitHub limits.
Cost of parallelism
Many parallel runners multiply cost on GitHub-hosted. At about 69 percent lower per-minute cost, wide sharding stays affordable.
Key takeaways
- Shard specs across a matrix.
- Auto-retry flaky browser tests.
- Warm pools for wide matrices; about 69 percent cheaper.
Related guides
How to Use Matrix Builds in GitHub ActionsUse GitHub Actions matrix builds to test across versions and OSes in parallel - strategy.matrix, include/excl…
Flaky Tests in CI: Causes, Detection, and ContainmentWhat makes tests flaky, how to detect flakiness, and how to contain it with quarantines and bounded retries w…
GitHub Actions Cost Calculator - Estimate & Cut Your CI BillFree GitHub Actions cost calculator: enter your monthly CI minutes and runner size to see your current bill a…