Cypress can automatically re-run a failed test a configured number of times (retries) before marking it failed, which absorbs occasional flakiness — but retries should mask rare noise, not hide real bugs.
In cypress.config.js you set retries (e.g. { runMode: 2, openMode: 0 }) so CI re-attempts a failing test up to N times; if any attempt passes, it is reported as passing (often flagged as flaky). This is useful for irreducible environmental noise, but over-reliance hides genuine defects and slows the suite. The right approach is to fix root causes: replace fixed waits with assertions/aliases, stub the network with cy.intercept, seed state via cy.request, and use data-cy selectors. Track flaky tests (Cypress Cloud surfaces them) and fix the top offenders rather than cranking retries up.
After enabling retries: { runMode: 2 } to stabilize CI, the team uses Cypress Cloud's flake analytics to find the three flakiest specs and fixes them by replacing cy.wait(ms) with request aliases — reducing flake instead of masking it.
Your CI is green only because retries are set to 3. Why is this risky and what should you do?