Playwright is flaky, but don't take our word for it
A result you cannot trust cannot gate a release, move a ticket, or save you time.
Playwright is flaky, but don't take our word for it.
What flake is
A flaky test is one that does not give the same answer for the same code. Same commit, same tests, different result. Green on your machine. Red in CI. Green if you run it again.
BrowserStack puts it simply:
Playwright tests that pass in one run and fail in another, without code or application changes, are flaky tests.
That is not a rare bug in one badly written spec. It is the usual complaint about Playwright packs: you cannot tell a product failure from a test that blinked.
A test like that does not give you confidence.
What people are already saying
These are from Playwright users, in their own words.
Is it just me or is Playwright maddeningly flaky at times?
I can run tests 50 times and I am guaranteed to have failed tests at least 10 times.
How Do You Handle Flaky Tests in Playwright + TypeScript?
My tests mostly run fine... but sometimes they’re flaky. Maybe 95% of the time they’re all green, but the other 5% is just randomness.
Playwright tests are solid locally but flaky in CI, what fixed it for you?
Tests were reliable locally, but flaky or slow in CI.
Playwright tests flaky in CI but stable locally
Tests are solid locally but intermittently fail in CI.
What’s your #1 trick to reduce flakiness in Playwright tests?
No matter how good Playwright is, some tests still end up flaky, especially on CI.
How to avoid writing Flaky Tests?
What are the techniques/best practices you follow to reduce the flakiness of tests?
After months of fighting flaky tests, the fix wasn't better waits.
Added waits. Added retries. Bumped timeouts. Tests still went red on CI and green on my machine.
The only thing worst than no tests are flaky tests
Do you want your org and engineers to have no trust in your work... Because flaky tests are how you get there.
Same story off Reddit. Latenode community:
We’re running about 200 Playwright tests across our app and it’s gotten ridiculous. Some days half of them fail, other days they pass.
May I know can I still fix the flaky or fail issue on test cases here?
Some replies will say the framework is fine and the tests are not. That may be true for a given spec. It does not change the fact that this is the conversation Playwright teams keep having.
Microsoft confirms it
Playwright's retries docs treat flake as a normal outcome:
This is useful when a test is flaky and fails intermittently.
"flaky" - tests that failed on the first run, but passed when retried
The CLI includes --fail-on-flaky-tests: fail the job if any test is flagged as flaky. Teams asked for that because a yellow result was being treated as a pass. GitHub issue 30457 is that request.
Microsoft and the Playwright communities are all aware of this issue. Unreliable test results have somehow become the norm. This should be considered completely unacceptable.
What flake actually costs
You stop believing the suite.
A red build might be a bug. It might be the same test as last Tuesday. After enough of that, people stop investigating. They rerun. The ticket stays where it is, or someone moves it because the second run was green.
You cannot embed that pack in automated CI workflows to close a ticket, merge a PR, or promote a build. The pipeline would be acting on a maybe. So a person stays in the loop. The automation never becomes a gate. It becomes something you babysit.
You also spend the time twice. Once on the product. Once on the framework: waits, retries, timeouts, quarantine tags, traces, "run it 50 times locally". That is not quality assurance.
Better Stack on the same point:
they erode team confidence in the test suite, waste developer time investigating false failures, and can lead teams to ignore legitimate test failures.
A flaky test is worse than no test. It teaches developers to ignore failures, slows merges, and erodes the trust that makes automation worth running.
Playwright might be free, but this is where you pay.
DoesQA
DoesQA is designed to be flake-free. Automatic waiting, fixed Selectors, and human-approved Selector updates mean a fail is something to investigate, not something to rerun until green.
Treat pass as shippable. Treat fail as real. Then CI can do the next step, including moving a ticket, because the Result is a Result.
If you're interested in finding out more, check out Maintenance and reliability or DoesQA vs Playwright: the same test compared. And if you're struggling with flakiness in Playwright, we would be happy to migrate your test pack into DoesQA (for free) so you can experience reliable, trustworthy results!
Start a trial. Cancel online.