Tests that pass on your laptop and fail in CI usually share a handful of causes. CI runners are slower and have less memory, so timing that was never tight locally becomes tight there. Tests running in parallel can collide over shared data that a single local run never shows. And no framework can know when your app is really ready for the next step.
Find the flake first
- Keep the evidence from the failed run, so you're not guessing from the error message alone.
- Run the failing test many times locally with retries off, so the flake shows up where you can look at it.
- Classify the failure: timing, shared data, an environment difference or an external service.
- Replace fixed delays with a wait on what actually needs to happen, such as a response arriving or a result appearing.
- Give each test its own data, with unique names and a fresh state.
- Fix the cause, then turn parallel runs back on. Retries are a safety net, not a fix.
Timing
A click can land while a dialog is still fading in. A search box can still show old results while a delayed request is on its way. The URL can change before the next page has loaded its data. The fix has the same shape each time: wait for the thing that means ready, not for an amount of time.
Shared data
Every test passes alone, but run the suite in parallel and a few fail at random. Usually two tests create the same user, or one empties a list another one counts. Each test should create its own data and not depend on what another left behind.
Accounts are the shared state most teams get wrong. Share one only when tests don't change the same server-side data; otherwise use separate accounts. If you save a signed-in session to reuse, treat it like a credential and keep it out of Git and shared artifacts.
CI is a different machine
A CI runner is slower than your laptop, has less memory and may render fonts differently. Memory limits can kill the browser mid-test, which often shows up as a confusing error rather than an out-of-memory message. Timezone and locale differ unless you pin them, so a date check written in one zone can fail in another.
Common mistakes
- Don't reach for retries first. A test that needs retries to pass will fail at the worst possible moment.
- Don't fix timing with a fixed delay. It's slow and still a guess.
- Don't turn parallel runs off for good. It hides data collisions and slows CI. Fix the shared data, then turn them back on.
- Don't ignore the first flake. It's the easiest one to diagnose; after twenty, the team has learned to ignore red builds.
- Don't blame Playwright by default. Most flakes come from test design or application behavior, not the framework.
Where Zerocheck fits alongside your suite
Keep the Playwright tests that earn their maintenance. Zerocheck suits the repeated manual browser flow your suite doesn't cover. Describe it in the web app with the same account, test data and expected outcome. Break the product on purpose and see whether the failure is easy to explain from the failing step, screenshots and console errors. Then move a control and look at what the run recorded. A pass after a transient retry stays labelled flaky.
What Zerocheck doesn't do
Zerocheck doesn't read, run, convert or repair Playwright tests, so it won't fix the flakes in your existing suite. It covers complete browser flows in Chromium rather than component tests, and it needs stable test data just as your suite does.