Shard tests across parallel jobs in GitHub Actions
Split one long test job into parallel shards with a matrix so the suite finishes in a fraction of the wall-clock time.
Do this
A test job that would run for many minutes as a single sequential run is split into N parallel shards via a matrix, each running its slice with the framework's native sharding flag (--shard for Playwright/Vitest/Jest, --partition for cargo-nextest, pytest-split for pytest). The critical path drops toward total / N plus per-job setup.1234567
jobs:
test:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shard: [1, 2, 3, 4]
steps:
# Node 24 action versions. As of 2026-07-14, Playwright's docs still show the Node 20
# v4/v5 (playwright.dev/docs/test-sharding); these are the current equivalents, same behavior.
- uses: actions/checkout@v7
- uses: actions/setup-node@v6
with:
node-version: 22
- run: npm ci
- run: npx playwright install --with-deps chromium
# strategy.job-total, not a literal 4: the denominator is the matrix size. Hardcode it
# and someone shrinks the matrix to [1, 2, 3] one day, the flag still says /4, and a
# quarter of the suite silently never runs. Green CI, untested code.
- run: npx playwright test --shard=${{ matrix.shard }}/${{ strategy.job-total }} --reporter=blob
# Each shard emits its own partial blob report. Keep them all, even when
# a shard fails, so the merge job below can see why.
- name: Upload blob report
if: ${{ !cancelled() }}
uses: actions/upload-artifact@v7
with:
name: blob-report-${{ matrix.shard }}
path: blob-report
retention-days: 1
# OTHER FRAMEWORKS: only the RUN step is portable. The artifact path and the merge job
# below are Playwright's, and copying them for another runner is how you get a green
# build with an empty report.
#
# Jest, no merge step; each shard reports on its own:
# - run: npx jest --shard=${{ matrix.shard }}/${{ strategy.job-total }}
#
# Vitest, same contract as Playwright but ITS OWN paths. Note the reporter flag: without
# it the shards pass, emit no blob, and the merge finds nothing. Vitest writes blobs to a
# HIDDEN directory, so the upload also needs `path: .vitest-reports/*` and
# `include-hidden-files: true` (upload-artifact defaults that to false and would upload
# zero files), and the merge is `npx vitest run --merge-reports`:
# - run: npx vitest run --reporter=blob --shard=${{ matrix.shard }}/${{ strategy.job-total }}
#
# pytest-split. Commit a .test_durations file (`pytest --store-durations`), or the groups
# are balanced by assumed-average time and the shards skew:
# - run: pytest --splits ${{ strategy.job-total }} --group ${{ matrix.shard }}
#
# cargo-nextest >= 0.9.127 (older versions use hash:m/n):
# - run: cargo nextest run --partition slice:${{ matrix.shard }}/${{ strategy.job-total }}
# Playwright only. Without this job the run ends with 4 partial reports
# instead of one. It runs even if a shard failed, so failures still show up.
merge-reports:
if: ${{ !cancelled() }}
needs: [test]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v6
with:
node-version: 22
- run: npm ci
- name: Download blob reports
uses: actions/download-artifact@v7
with:
path: all-blob-reports
pattern: blob-report-*
merge-multiple: true
- run: npx playwright merge-reports --reporter html ./all-blob-reports
- name: Upload HTML report
uses: actions/upload-artifact@v7
with:
name: html-report--attempt-${{ github.run_attempt }}
path: playwright-report
retention-days: 14Avoid this
The whole suite runs on one runner, so the PR waits on a single long pole.
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- run: npx playwright test # every spec, one runner, one long poleSeen in the wild
Real workflow files from public projects.
fail-fast: false
matrix:
os: [ubuntu-latest, macos-latest]
node-version: [22]
shardIndex: [1, 2]
shardTotal: [2]
shardWeights: ['58:42'] strategy:
fail-fast: false
matrix:
shard: [1, 2, 3, 4] matrix:
shard: [1, 2, 3, 4, 5, 6, 7, 8]
# ...
- name: Run Tests
run: yarn e2e --shard=${{ matrix.shard }}/${{ strategy.job-total }} --workers=4non-adjacent lines joined by # ...
Why it matters
Sharding is a top wall-clock lever: it directly parallelizes your slowest test job. The honest tradeoff is that it trades runner-minutes for speed, the same tests still run, and each extra shard adds fixed setup overhead (checkout, install), so your bill goes up even as the critical path comes down. Stack it with dependency and build caching so per-shard setup doesn't eat the gains, and make sure your runners have enough concurrency to start every shard at once instead of queueing.
When to use
Use it when
Any test job whose wall-clock is over ~5 minutes and whose framework supports sharding.
Be careful when
When the suite is short, or when per-job setup already dominates the runtime, past a point, adding shards stops moving wall-clock because the setup tax floors it. Fix caching first, then shard.
Verify on your repo
Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.
Inspect this repo's .github/workflows for a long test job that runs the whole suite on a single runner with no `matrix` shard axis. Identify the slowest test job (wall-clock over ~5 minutes) and confirm its framework supports sharding (`--shard` for Playwright / Jest / Vitest, `--partition` for cargo-nextest, `pytest-split` for pytest). Add a `matrix` with a `shard` axis and pass the framework's native sharding flag so the suite splits across N parallel jobs, and make sure dependency and build caching is in place so per-shard setup does not eat the gains. Show me the diff and open a PR rather than applying it blindly.
Ground these changes in the upstream docs before you edit: https://playwright.dev/docs/test-sharding, https://github.com/jerry-git/pytest-split. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.Prefer to check by hand?
Identify test jobs with wall-clock over ~5 minutes.
Check whether the framework supports sharding (
--shardfor Playwright/Jest/Vitest,--partitionfor nextest,pytest-split).Confirm no
matrixshard axis is configured, a single job running the whole suite is the flag.
Automate this with StarSling.
Rather than audit this by hand, install the StarSling GitHub App: it opens a pull request to move your workflows onto StarSling runners, then its agents keep reading your jobs, run logs, and machine telemetry and open pull requests that fix what this page covers, along with caching, parallelization, and test sharding across the rest of your pipeline. Every change arrives as a PR you review and merge.
More best practices for GitHub Actions
Where to go next in the CI best-practices catalog.
- Parallelization
Build and test only what changed in GitHub Actions
Scope your slowest build/test job to only the packages a PR actually changed, using your monorepo tool's affected mode, with a mandatory full-run fallback so a resolution error never silently skips work.
- Caching & Setup
Cache dependencies in GitHub Actions
Cache your package manager's downloads so CI restores dependencies from a keyed cache instead of reinstalling them from scratch on every run.
FAQ
Does sharding save money or just time?
Just time. Sharding lowers wall-clock (the critical path) but raises runner-minutes, because the same test work runs across more jobs and each shard repeats setup. It's the right lever when speed matters more than the bill, pair it with caching to keep the added overhead small.
How many shards should I use?
Increase shards until the per-shard setup overhead (checkout, install, browser download) starts to dominate, that's the floor. Caching that setup lets you shard further before diminishing returns kick in.
What is the shard command for Jest, Vitest, or pytest?
The matrix is the same for all of them, and every shard flag below is 1-based. What changes is whether you also need a merge step. Playwright and Vitest both do: pass --reporter=blob and each shard writes a partial blob report, so without a merge job you finish with N of them instead of one. Playwright merges with npx playwright merge-reports; Vitest merges with npx vitest run --merge-reports, a mode that reads the existing blobs rather than running the tests again. Watch out for one Vitest difference: it writes its blobs to a hidden directory, so its upload step also needs include-hidden-files: true, which actions/upload-artifact defaults to false. Jest takes the same flag (npx jest --shard=${{ matrix.shard }}/${{ strategy.job-total }}) and has no built-in merge, so each shard reports on its own. pytest has no built-in sharding: install pytest-split, run pytest --splits ${{ strategy.job-total }} --group ${{ matrix.shard }}, and commit a .test_durations file (pytest --store-durations) or the groups are balanced by assumed-average time and the shards skew. Rust uses cargo-nextest 0.9.127 or newer: cargo nextest run --partition slice:${{ matrix.shard }}/${{ strategy.job-total }}.
Sources
1Playwright · test sharding (opens in new tab)
2GitHub Actions · matrix strategy (opens in new tab)
3Jest CLI · --shard (opens in new tab)
4Vitest CLI · --shard (opens in new tab)
5Vitest · sharding needs --reporter=blob and --merge-reports (opens in new tab)
Last updated 2026-07-15
Run the suite in parallel, not in sequence.
One line to install. Faster runs on day one, and agents that open reviewable PRs to keep your pipeline following practices like this one.