Sharded Tests

You'll need

• Getting Started complete
• a test runner that supports sharding

You'll have

• every commit with one merged report on the dashboard, even when the tests ran across N parallel shards.

Shard

A shard is a slice of your test suite that runs on a separate CI job. Sharding speeds up CI by running tests in parallel. Each shard produces its own partial report.

Sharding is a test-runner feature

Sharding happens in your test runner, not in Flakiness.io. Each runner has its own way to split the test suite across N workers — consult your runner’s documentation:

• Playwright Test — Sharding
• Vitest — --shard CLI flag
• Pytest — pytest-split (true sharding via --splits N --group K; pytest-xdist parallelizes across workers on a single machine, which is different)
• CucumberJS — Sharding

Configure your CI (matrix or parallel jobs) to run each shard in its own job, invoking the runner with the appropriate shard flag. This is standard CI work and follows your provider’s conventions.

How Flakiness.io merges the shards

Flakiness.io joins shard reports automatically. No platform-side configuration is needed. The match key is:

• same commit SHA, and
• same environment

Each shard produces its own report. When both the commit SHA and the environment match, Flakiness.io merges them into one unified view on the dashboard.

If the environments differ between shards (for example, shards 1–2 on Linux and shards 3–4 on Windows), you’ll get two separate histories, which is usually what you want.

Related

• Configuring Environments — deliberately split histories (staging vs prod, etc.).
• Running Tests Across Operating Systems — the OS matrix is a shard-ish pattern where you do want separate histories.