Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A Cypress test that passes on retry passed eventually, but its first failure is still a useful signal. The green status does not establish that the test is reliable: Cypress says a test can pass after retries and still be flaky. Read the failed attempt, compare it with the pass, and determine whether a change introduced a regression or the test has been unstable for longer.
What a Cypress pass after retry actually means
The test’s assertions passed on a later attempt. They did not pass on the first attempt, and the retry does not explain why. Cypress Cloud can show the error and stack trace from each attempt alongside artifacts, run history, and commit context. Its guidance recommends distinguishing a new regression from an existing intermittent problem.
A passing result also says only that the assertions the test actually contains passed. Cypress notes that a spec with all tests skipped can report as passed. Check that the expected tests ran and that the assertions cover the behavior you care about; do not treat the status alone as proof of coverage.
In Cypress Cloud’s CLI output, a flaky test may have a passed status and still contain multiple attempts. Look at the attempt count and per-attempt errors rather than reading the final status in isolation. See Cypress Cloud CLI documentation and Cypress Cloud’s flaky test guidance.
Test retries and command retry-ability are different
Test retries rerun the test
A configured test retry starts another execution after a failed attempt. Cypress reruns the test, including its beforeEach and afterEach hooks. With retries: 2, a test can run up to three times in total. That can help a transient failure avoid failing a run, but it also adds execution time and can conceal recurring instability if nobody reviews the recovered tests.
Cypress’s performance guide gives illustrative worst-case examples: two retries add up to 10 seconds for a 5-second test, or 30 seconds for a 15-second test. Those are calculations for the examples, not general measurements. Cypress recommends treating retries as a safety net, keeping them deliberate, and fixing tests that frequently need them. It suggests a small CI safety net and no retries in local open mode as one possible configuration, not a universal requirement. See Cypress’s test performance guide.
Query retry-ability retries a chain within one attempt
Cypress’s query retry-ability repeatedly evaluates eligible command chains and their assertions while a test attempt is running. This is distinct from rerunning the whole test. For example, an assertion chained directly to cy.wait() runs once; a query such as .its() followed by .should() can retry. See Cypress’s retry-ability guide and the cy.wait() API documentation.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →How to investigate the failed attempt
- Open the test’s detail view. Read the first error and stack trace, then inspect each attempt rather than stopping at the final pass. Note which assertion failed and what Cypress reported immediately beforehand.
- Check the run history and commits. See whether the test began failing around a code or test change. If recorded runs exist for both the current branch and its base, Cypress Cloud’s Branch Review can help compare them. A failure that predates the change points toward existing instability; a new pattern after a change merits regression investigation.
- Compare the failed and passing replays. Use the attempt timelines, commands, network activity, logs, and available artifacts. Look for a slower command, a late response, or values that differ between attempts. These are clues, not proof of a particular cause.
- Trace the changing condition. Ask whether the test depended on uncertain DOM state, timing, a race between application work and an assertion, or an environmental dependency. Cypress identifies these as areas to investigate; the replay evidence is needed to narrow down the cause.
- Verify what the test actually exercised. Confirm the relevant test ran, was not skipped, and asserted the user-visible or application state that matters. A retry cannot compensate for an absent or insufficient assertion.
Cypress’s flaky test guidance and CLI documentation describe reviewing attempt errors, artifacts, history, and replay timelines. The available evidence can help separate a regression from an older flaky test, but it cannot identify the cause without the test’s own attempts and artifacts.
Fix the source of nondeterminism
Make state and setup reliable
If the test chooses a path based on DOM state that may vary, make the relevant state reliable before asserting or acting. Cypress’s conditional-testing guidance warns that decisions based on uncertain DOM state can be nondeterministic; supply dependable state and facts to the test instead. Review setup, data, and external dependencies when the attempts differ in what state they observe. See Cypress’s conditional-testing guide.
Synchronize on the event, not an arbitrary delay
A fixed sleep may slow the suite and still fail to cover every timing variation. Where a network response is the condition that matters, wait for a specific intercepted request, then assert the relevant response or resulting UI state with a retryable query where appropriate. Cypress’s cy.wait() documentation explains that assertion behavior depends on the chain: a directly chained assertion runs once, while a query followed by .should() retries.
Use retries as a signal, not a cure
Keep retry settings deliberate and pay attention to tests that repeatedly recover. A pass on retry is evidence that a later execution satisfied the test’s assertions; the earlier failure remains evidence of instability that deserves investigation. Cypress describes retries as a safety net, not a fix. Review attempt history and correct the underlying nondeterminism rather than letting a green run erase the signal.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
