A Cypress test that passes after a retry is green for that run, but the first failure still matters. Cypress’s documentation puts it plainly: “A test can pass after retries and still be flaky.” Treat the failed attempt as evidence to investigate, not as a problem erased by the later pass.
What a passing retry actually tells you
The test’s assertions passed on a later attempt; they did not pass consistently. Cypress also cautions that a passing test proves only that the assertions you wrote were satisfied. If an important outcome is not asserted—or a test was skipped—the green status does not establish that the behavior is correct. See the Cypress FAQ.
As an Amazon Associate I earn from qualifying purchases.
In Cypress Cloud, a test can show a passed status even though it took multiple attempts. Check the attempt count and each attempt’s error rather than relying on the final status alone. The Cypress Cloud CLI guide explains how to identify passed tests with multiple attempts and inspect their timelines.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Know which kind of retry happened
Query and assertion retry-ability
Within an attempt, Cypress can repeatedly evaluate a query chain and its retryable assertions while waiting for the expected state. This helps with state that takes time to appear, but it does not rerun the entire test. The details depend on the command chain: an assertion chained directly to cy.wait() runs once, whereas a query such as .its() followed by .should() can retry. Cypress documents these distinctions in its cy.wait() API reference.
Configured test retries
A test-level retry reruns the failed test. Cypress’s performance guidance notes that each retry re-executes the test, including its beforeEach and afterEach hooks. With retries: 2, a test can run up to three times total. Cypress illustrates the possible cost: a five-second test with two retries can add up to ten seconds in the worst case; a 15-second test can add up to 30 seconds. Those are examples, not measured averages. See Cypress’s test performance guide.
Compare the failed attempt with the passing one
- Open the test’s detail view. In Cypress Cloud, review the attempt errors and stack traces, artifacts, recent pass/fail history, and commits associated with changes. The flaky test management guide describes these diagnostics.
- Read the first failure before the retry’s success. Note the command, assertion, and stack location that failed. The first error may identify a specific expectation or operation that the final status obscures.
- Compare the attempt timelines. Look at commands, network activity, logs, and timing in both the failed and passing attempts. A slower command, late network response, or changed value may offer a clue; none proves a cause on its own. Cypress’s CLI guidance explains how to inspect attempts.
- Check whether the problem is new. Compare the current branch with its base and review relevant commits. Cypress Cloud’s Branch Review can make this comparison when recorded runs exist for both branches. A failure that predates the change suggests existing instability; a new failure associated with a change warrants regression investigation.
- Look for uncertainty in setup and state. Ask whether the test depends on a request finishing, data being present, or the DOM reaching a particular state before the next action. Race conditions, timing, and environmental dependencies are possibilities to investigate—not conclusions you can draw from a retry alone.
Make the test wait for evidence, not a guessed duration
When a test depends on a network response, intercept the specific request and wait for it, then assert the relevant response or resulting UI state. Use a retryable query and assertion for UI state that may take time to settle. A fixed sleep does not confirm that the condition you need is true: Cypress warns that arbitrary delays can slow a test and still leave opportunities for flake. Its conditional testing guide also cautions against branching on uncertain DOM state; provide reliable state and facts to the test instead.
Review the assertions themselves as well. Assert the user-visible outcome that matters, and make sure setup leaves the test with known data and state. If the test can pass without checking the behavior that prompted it, a retry cannot make that coverage stronger.
Use retries as a safety net, not a repair
Cypress recommends keeping retries deliberate: its guidance suggests a small safety net in CI and no retries in local open mode, while emphasizing that frequently retrying tests are technical debt to fix. Choose a policy that suits your project, but track tests that repeatedly recover and investigate their attempt histories. A retry can reduce the chance that one intermittent failure blocks a run; it cannot establish that the behavior is reliable or remove the cause of the instability.
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.
