Flakiness is usually a test or environment problem you can trace to a short list of causes. Fowler lists lack of isolation, asynchronous behavior, remote services, time, and resource leaks. Google reports that about 1.5% of its test runs are flaky, almost 16% of its tests show some flakiness, and about 84% of pass-to-fail transitions in its CI involved a flaky test, with root causes such as concurrency, non-deterministic behavior, flaky third-party code and infrastructure problems. To find yours, re-run the failing test alone and in the whole suite, run in random order, inspect the trace of the failing run, and look for fixed sleeps, shared data, clock or timezone dependence and real network calls. Remember that a flaky test can also be exposing a genuine race in the product.

Most causes have a standard fix: replace fixed sleeps with web-first assertions and auto-waiting, give each test its own data and account through factories, and stub unstable external APIs with route interception. While a fix is in progress, move the test to a quarantine job that still runs and reports but does not block the main branch.

Sources: Google Testing Blog, Fowler: Eradicating Non-Determinism in Tests, Playwright retries