flaky in the run summary and in the JSON report's stats.flaky. It also marks them ok, so the process exits zero and the build goes green. retries is an evidence-collection setting. Turning it on without reading the flaky list is how a team pays for the evidence and then throws it away.Here is the run that starts this problem. A pull request is green. The check is green, the merge button is green, and in the terminal output, forty lines above the summary, sits this:
\n\n 1 flaky\n example.spec.ts:5:2 › second flaky\n 2 passed (4s)Nobody read it, because nothing asked them to. The exit code was zero, GitHub showed a tick, and the reviewer looked at the diff. Six weeks later the same test fails on the first attempt and all three retries, someone opens the trace, and the failure turns out to be a race the team has been paying for since a config change in March. The signal was never missing. It was emitted, recorded, and discarded on every single run.
\n\nThe retries documentation defines three categories precisely, and the precision matters:
\n\nSo \"flaky\" in Playwright is not a heuristic, a score, or a judgement about a test's character. It is a mechanical fact about one execution: at least one attempt was red, and a later attempt was green. A test can be labelled flaky today and passed tomorrow, and both labels are correct records of what happened.
\n\nTwo different properties encode this, and conflating them is the root of most broken flake tooling.
\n\ntestResult.status is the status of one attempt: 'passed' | 'failed' | 'timedOut' | 'skipped' | 'interrupted'. Each retry produces its own TestResult with its own status and its own retry index, and they all live in testCase.results.
testCase.outcome() is the verdict over all attempts: 'skipped' | 'expected' | 'unexpected' | 'flaky'. The documentation is explicit that outcome is not the same as testResult.status, and gives the two cases that prove it: a test expected to fail that does fail is 'expected', and a test that passes on a second retry is 'flaky'.
\"Expected\" is doing real work there. testCase.expectedStatus is 'passed' for ordinary tests, 'skipped' for anything marked test.skip() or test.fixme(), and 'failed' for anything marked test.fail(). Outcome is the comparison of actual against expected, not the raw actual. This is why \"did the test pass\" is the wrong question to ask a reporter, and outcome() === 'flaky' is the right one.
Inside a test, the same fact is available as testInfo.retry: zero on the first run, one on the first retry, and so on. It is readable from any test, hook or fixture.
Playwright surfaces flakiness in every built-in reporter. The list reporter prints a flaky block with the test titles. The dot reporter has a dedicated character for it: ± means \"passed on retry (flaky)\", distinct from ×, which means \"failed or timed out — and will be retried\". The HTML report keeps the failed attempt alongside the passing one.
The JSON reporter carries it as structured data, in two places. Per test, JSONReportTest.status is one of 'skipped' | 'expected' | 'unexpected' | 'flaky'. And at the top of the document, already aggregated for you:
{\n \"stats\": {\n \"startTime\": \"2026-03-11T08:14:02.118Z\",\n \"duration\": 412803,\n \"expected\": 611,\n \"unexpected\": 0,\n \"flaky\": 9,\n \"skipped\": 4\n }\n}Now the part that decides everything. In Playwright's own runner, the ok flag on a spec is computed as test.outcome() === 'expected' || test.outcome() === 'flaky'. Flaky counts as ok. And testCase.ok() is documented as \"whether the test is considered running fine. Non-ok tests fail the test run with non-zero exit code.\"
That is the whole failure. Playwright classified the run correctly, wrote nine flaky tests into a machine-readable file, and then exited zero because flaky is ok. CI reads the exit code. Nothing in the default pipeline reads stats.flaky. The evidence exists at full fidelity and has no consumer.
retries: 2 in playwright.config.ts, the JSON or blob reporter enabled, no job step that opens the report, and no metric anywhere with the word \"flake\" in it. Every element is individually defensible. Together they mean the team is running each unstable test up to three times a day and storing the results where nobody looks.Since v1.52 there is a blunt instrument for this: failOnFlakyTests in the config, or --fail-on-flaky-tests on the command line. It exits with an error if any test is marked flaky.
// playwright.config.ts — the blunt version\nimport { defineConfig } from '@playwright/test';\n\nexport default defineConfig({\n retries: process.env.CI ? 2 : 0,\n failOnFlakyTests: !!process.env.CI,\n});On a small, healthy suite this is the right answer and you should stop reading this section. On a suite of 600 browser tests hitting a real backend it is not, for a reason that is arithmetic rather than ideology. If a single test has a genuine 0.5% first-attempt failure rate from causes outside your test code — a slow CDN response, a container that took an extra second to become healthy — then across 600 tests you expect roughly three flaky labels per run. failOnFlakyTests turns that into a red build on most runs, and a check that is red most of the time gets ignored or bypassed within a fortnight. You have moved the blindness, not removed it.
The gate that survives contact with a large suite is a rate gate with a threshold you chose deliberately, plus a named-test gate for repeat offenders. Rate is a property of the suite; individual flaky labels are noise on top of it.
\n\nStart by keeping the raw evidence. Reporters compose, so add JSON without giving up readable terminal output:
\n\n// playwright.config.ts\nimport { defineConfig } from '@playwright/test';\n\nexport default defineConfig({\n // Retries buy evidence: a second data point on whether the failure reproduces.\n // They do not buy a green build — the gate below decides that.\n retries: process.env.CI ? 2 : 0,\n\n // Deliberately NOT failOnFlakyTests. The rate gate owns this decision.\n failOnFlakyTests: false,\n\n use: {\n // Keeps the failed attempt's trace even though a later retry passed.\n trace: 'retain-on-failure',\n },\n\n reporter: process.env.CI\n ? [\n ['github'],\n ['html', { open: 'never' }],\n ['json', { outputFile: 'flake-evidence/results.json' }],\n ]\n : 'list',\n});Then post-process. This script reads nothing but the JSON report, so it works unchanged whether the report came from one machine or from merged shards:
\n\n// scripts/flake-gate.mjs\n// Usage: node scripts/flake-gate.mjs flake-evidence/results.json\nimport { readFileSync } from 'node:fs';\n\nconst THRESHOLD_PCT = 1.5; // suite-wide budget\nconst REPEAT_OFFENDERS = new Set([ // known-bad, individually gated\n 'checkout.spec.ts:88:5 › applies a promo code',\n]);\n\nconst report = JSON.parse(readFileSync(process.argv[2], 'utf8'));\nconst { expected, unexpected, flaky, skipped } = report.stats;\n\n// Skipped tests never ran, so they do not belong in the denominator.\nconst executed = expected + unexpected + flaky;\nconst rate = executed ? (flaky / executed) * 100 : 0;\n\n// Walk the suite tree to name the offenders — stats alone cannot.\nconst names = [];\nconst walk = (suite) => {\n for (const spec of suite.specs ?? [])\n for (const t of spec.tests)\n if (t.status === 'flaky')\n names.push(`${spec.file}:${spec.line}:${spec.column} › ${spec.title}`);\n for (const child of suite.suites ?? []) walk(child);\n};\nreport.suites.forEach(walk);\n\nconsole.log(`flake rate ${rate.toFixed(2)}% (${flaky}/${executed}), budget ${THRESHOLD_PCT}%`);\nfor (const n of names) console.log(` flaky: ${n}`);\n\nconst overBudget = rate > THRESHOLD_PCT;\nconst offender = names.find((n) => REPEAT_OFFENDERS.has(n));\n\nif (offender) {\n console.error(`gate failed: quarantined test flaked in the main lane — ${offender}`);\n process.exit(1);\n}\nif (overBudget) {\n console.error(`gate failed: flake rate ${rate.toFixed(2)}% exceeds ${THRESHOLD_PCT}%`);\n process.exit(1);\n}\nconsole.log(`gate passed; skipped: ${skipped}`);Note the two exits are different failures with different owners. Over-budget is a suite health problem for the team. A quarantined test flaking in the main lane means quarantine leaked, which is a process problem.
\n\nIf you would rather the decision live inside Playwright than in a separate step, a custom reporter can override the run's exit status directly. onEnd is documented as being allowed to override the status and hence affect the exit code, by returning an object with a status field:
// reporters/flake-budget.ts\nimport type { FullResult, Reporter, Suite } from '@playwright/test/reporter';\n\nclass FlakeBudget implements Reporter {\n private suite!: Suite;\n constructor(private options: { maxPercent: number } = { maxPercent: 1.5 }) {}\n\n // Returning false lets Playwright keep a normal terminal reporter alongside.\n printsToStdio() { return false; }\n\n onBegin(_config: unknown, suite: Suite) { this.suite = suite; }\n\n async onEnd(result: FullResult) {\n const tests = this.suite.allTests();\n const executed = tests.filter((t) => t.outcome() !== 'skipped');\n const flaky = executed.filter((t) => t.outcome() === 'flaky');\n const pct = executed.length ? (flaky.length / executed.length) * 100 : 0;\n\n for (const t of flaky) {\n const attempts = t.results.map((r) => r.status).join(' → ');\n console.log(`FLAKY ${t.titlePath().join(' › ')} [${attempts}]`);\n }\n\n if (result.status === 'passed' && pct > this.options.maxPercent) {\n console.error(`flake budget blown: ${pct.toFixed(2)}%`);\n return { status: 'failed' as const };\n }\n }\n}\nexport default FlakeBudget;The t.results.map(r => r.status) line is the useful part: it prints the attempt sequence, so timedOut → passed and failed → failed → passed stop looking like the same event. They are not. The first is usually an environment or waiting problem; the second is usually a genuine race.
Wire whichever version you chose into CI so that the report is produced even when tests fail:
\n\n# .github/workflows/e2e.yml\n- name: Run end-to-end tests\n run: npx playwright test\n\n- name: Flake gate\n if: always()\n run: node scripts/flake-gate.mjs flake-evidence/results.json\n\n- name: Keep the evidence\n if: always()\n uses: actions/upload-artifact@v4\n with:\n name: flake-evidence\n path: |\n flake-evidence/results.json\n playwright-report/\n retention-days: 30if: always() on the upload step is not decoration. Without it, the artifact upload is skipped precisely on the runs where the evidence mattered.
A test that flakes repeatedly should leave the blocking lane. The dishonest version of that is test.skip() with a Jira ticket in a comment, which is indistinguishable from deletion after the second sprint: it no longer runs, no longer reports, and no longer appears in any count except stats.skipped.
Honest quarantine keeps the test running, keeps it visible, and keeps it attached to a person. Tags are the mechanism, because a tag is queryable from the CLI and shows up on testCase.tags.
// checkout.spec.ts\nimport { test, expect } from '@playwright/test';\n\n// Wrong: silent, unowned, permanent.\n// test.skip('applies a promo code', async ({ page }) => { /* ... */ });\n\n// Right: still runs, in its own lane, with an owner and an expiry.\ntest('applies a promo code', {\n tag: '@quarantine',\n annotation: [\n { type: 'quarantine-owner', description: 'checkout-team' },\n { type: 'quarantine-until', description: '2026-04-15' },\n { type: 'issue', description: 'https://example.com/issues/4471' },\n ],\n}, async ({ page }) => {\n // ...\n});Tags must start with @, and they can also be written as @-tokens in the title, which testCase.tags extracts. The details object is clearer for anything you intend to read programmatically.
Then split the lanes. The blocking job excludes the tag; a second, non-blocking job runs only the tag:
\n\n# Blocking lane: quarantined tests cannot break the merge.\nnpx playwright test --grep-invert @quarantine\n\n# Observation lane: runs the quarantined tests, allowed to fail the job's\n# status without failing the merge. Extra retries here are pure data.\nPLAYWRIGHT_JSON_OUTPUT_NAME=quarantine.json \\\n npx playwright test --grep @quarantine --retries=4 --repeat-each=5 \\\n --reporter=jsonThe observation lane is where quarantine earns its keep. Five repetitions with four retries each gives a real failure rate for that test, rather than the single bit of information a normal run produces. Feed its stats into the same script and you have a per-test number to argue from.
The expiry matters more than the tag. Add a check that reads the annotations and fails if a quarantine-until date has passed. Without it, quarantine is test.skip() with extra steps.
A quarantined test can only be fixed from the failing attempt, and the failing attempt is the one your defaults are most likely to discard.
\n\nThe trace modes differ in exactly this respect, and the distinction is documented:
\n\n'on-first-retry' — records a trace only for the first retry. The original failure is not captured. If the retry passes, you have a trace of a successful run, which is the least useful artefact available.'retain-on-failure' — records a trace for every run but keeps it only for runs that failed, and a failed run's trace is kept even when a later retry passes. This is the mode that preserves flake evidence.'retain-on-failure-and-retries' — keeps a trace for any run that failed or that is a retry, so you get the failure and the passing retry side by side. Larger artefacts, best diffing.Video accepts the same modes. Screenshots use a different set: 'off' | 'on' | 'only-on-failure' | 'on-first-failure'.
Beyond artefacts, attach the environment facts a trace cannot contain. testInfo.retry tells you when you are on a retry, so you can label the attempt and capture backend state that will otherwise be gone:
// fixtures/evidence.ts — import this file from your spec files, or add it\n// to the project's setup so the hook applies suite-wide.\nimport { test } from '@playwright/test';\n\ntest.afterEach(async ({ page }, testInfo) => {\n if (testInfo.status === testInfo.expectedStatus && testInfo.retry === 0) return;\n\n await testInfo.attach(`attempt-${testInfo.retry}-context.json`, {\n contentType: 'application/json',\n body: Buffer.from(JSON.stringify({\n attempt: testInfo.retry,\n status: testInfo.status,\n expectedStatus: testInfo.expectedStatus,\n durationMs: testInfo.duration,\n url: page.url(),\n buildSha: process.env.GITHUB_SHA,\n workerIndex: testInfo.workerIndex,\n }, null, 2)),\n });\n});Comparing testInfo.status against testInfo.expectedStatus rather than checking for 'failed' is what makes this correct for tests marked test.fail(), whose expected status is 'failed'. Attachments land in testResult.attachments and appear in the HTML report against the specific attempt that produced them.
If you shard, use the blob reporter and merge. Blob reports contain all the details about the test run and exist to make sharded reports mergeable; running your gate against per-shard JSON gives you per-shard rates that are individually too small to be meaningful.
\n\nThe denominator drifts. A rate expressed against a test count changes when someone adds 200 tests, and the same absolute number of flaky runs suddenly looks healthier. If your suite size moves a lot, gate on both: a percentage and an absolute ceiling on flaky count.
\n\nSerial mode inflates the count. In test.describe.serial(), all tests in the group are retried together. A single unstable test at position two causes the whole group to re-run, and every test in it that failed then passed is legitimately labelled flaky. One root cause, five flaky labels. Look at whether your flaky list clusters inside serial blocks before concluding the suite is degrading.
The gate is advisory. A job that prints a warning and exits zero is read for two weeks and ignored thereafter. The gate has to be able to turn the build red, on a rate the team agreed to, or you have rebuilt the original problem with more YAML.
\n\nAdd ['json', { outputFile: 'flake-evidence/results.json' }] to your CI reporter array and upload it as an artifact with if: always(). Do not add a gate yet. Run for a week and read stats.flaky against stats.expected + stats.unexpected + stats.flaky on each run.
That gives you your suite's actual flake rate, which is the number you need before choosing a threshold. Set the budget slightly below the observed rate so the gate has something to do on day one, tag the two or three tests responsible for most of the count into @quarantine with an owner and an expiry date, and switch trace to 'retain-on-failure' so the next flake arrives with the failing attempt attached.
No, not by default. Flaky counts as ok, and only non-ok tests fail the run with a non-zero exit code. Set failOnFlakyTests (or pass --fail-on-flaky-tests) if you want any flaky result to fail the run, or compute a rate yourself from the JSON report.
retries: 0 instead?That trades one blind spot for another. With no retries you cannot tell an intermittent failure from a deterministic one without re-running by hand, and the first data point about reproducibility is exactly what a retry gives you. Keep retries, and stop treating a passing retry as the end of the matter.
\n\nNo. Flake rate counts only tests that failed and then passed. A test that fails all its retries is unexpected, not flaky, and never enters the flaky count no matter how unstable it is. If you want first-attempt failure rate, count results with retry === 0 and a status other than 'passed' across testCase.results.
Yes. test.describe.configure({ retries: 2 }) sets retries for a describe group or a single file. Treat it as a declaration that the file is unstable, not as a fix, and pair it with the same visibility you would apply anywhere else.
Usually because CI runs more tests concurrently against shared external state. Playwright discards the entire worker process and its browser after a failure and starts a new one, so browser state is not the cause. Look at what your tests share outside the browser: seeded rows, fixed ports, accounts, files.
\n\ntestInfo.retry, per-describe retries, and serial-mode group retry behaviour± character, JSON and blob reporter options, and the custom reporter skeletonoutcome() versus ok(), expectedStatus, results, and tagsstatus values, retry index, and attachmentsonEnd overriding the run status and exit code, and printsToStdiofailOnFlakyTests, added in v1.52--grep and --grep-invert