Find why a Playwright test is flaky before adding another retry.
Start with the first contradiction: timing, shared state, test data, network behavior, or locator drift. When the browser path matters, preserve it so the receiving engineer can inspect what differed.
Capture the unstable element from the failing page.
Compare selector alternatives against real UI state.
Route the same artifact into engineering handoff, replay context, and export.
Built for failure analysis
The workflow preserves the failing UI state instead of assuming the locator problem is obvious.
Selector and replay context stay together
Teams can link the exact element to a broader bug reproduction thread when needed.
Shared evidence for QA and engineering
The person reporting the failure and the engineer fixing the UI can inspect the same captured state.
Five common causes of flaky Playwright tests
Flake usually comes from one of five buckets: timing and asynchronous UI work, leaked state between tests, unstable or reused data, variable network or service behavior, and locators whose contract changed.
Classify the failure before changing the test. More retries can hide every one of these causes without removing it.
A practical Playwright flake triage order
Re-run the smallest failing test with trace and network evidence, identify the first state that differs from a passing run, check isolation and data, then review waits and locators. If the path or target is the contradiction, preserve that deliberately initiated browser flow for the engineer receiving the failure.
Reproduce the smallest failing scope without changing retries.
Compare the first contradiction, not only the final assertion.
Check state, data, network, timing, and locator causes in that order.
Apply one fix and verify it across repeated clean runs.
Hand off the first contradiction, not only the final failure.
Keep the relevant path, target, and supporting evidence together so engineering can review the cause before changing retries or locators.