Before you rerun a flaky test, read the first failure. A rerun can change or overwrite the evidence you need, and timing problems, shared state and flaky services can all look alike from the outside.
Sort the failure first
| What you see | Likely cause | What to do |
|---|---|---|
| The element wasn't found, and the page looks right | Locator or timing | Wait for meaningful app state, not a fixed delay |
| The page shows the wrong data | Shared or stale test data | Check the account and fixture state |
| The expected outcome failed, and it fails again | Product bug, or a changed requirement | Reproduce it and fix the product or update the test |
| Network or service errors | An external dependency | Separate it from product failures |
A locator failure and a failed product assertion need different fixes, so don't treat them as one problem. Equally, not every infrastructure error is a product bug.
Review the expected outcome
If a test verifies "success" without saying which record or value should exist, a green result is hard to interpret. Tighten the expectation and make sure the fixture is stable before you look into targets or timing.
Give it an owner
Assign someone to the root cause before you go back to trusting the merge gate. Retrying assertion failures until they pass only teaches people to ignore red builds.
What a flaky result means in Zerocheck
Open the run to see the failing step, its screenshots, the console errors and the type of failure. If a transient AI-service error is retried in the same browser and the test then passes, it's labelled flaky in the results and the CLI. Failed outcomes aren't retried, and a failed test isn't replayed after its browser actions have run, because that could repeat a write.
A healed target is a separate thing from a retry. The run shows healing in its own history, so you can review it on its own. If a flaky pass should fail your CI job, add --fail-on-flaky.