How to fix flaky Cypress tests in CI

Approach 1: Debug and fix Cypress-specific flakes

1. 1.Enable screenshots on failure (screenshotOnRunFailure: true) and video recording (video: true) in cypress.config.ts to capture exactly what the browser showed when a test failed
2. 2.Use Cypress Dashboard or Cypress Cloud to track which tests flake most frequently and identify patterns (timing, environment, specific specs)
3. 3.Replace all cy.wait(ms) calls with cy.intercept() and cy.wait('@alias') to wait for specific network requests instead of guessing at delays
4. 4.Add .should('be.visible') or .should('exist') guards before interacting with elements that may be re-rendered by your SPA framework
5. 5.Set numTestsKeptInMemory: 0 in cypress.config.ts to reduce memory pressure in large suites running in CI
6. 6.Split large spec files into smaller ones and use --spec glob patterns to run subsets in parallel across CI containers

The cy.wait() trap

The single most common cause of flaky Cypress tests is cy.wait() with a hardcoded millisecond value. It shows up in almost every Cypress codebase, and it is almost always wrong. The pattern looks like this: a test clicks a button that triggers an API call, then waits an arbitrary number of milliseconds before asserting on the result. cy.wait(3000) works on your MacBook because the API responds in 200ms and the UI updates within a second. In CI, the same API call takes 1.5 seconds because the runner is sharing resources with 20 other jobs. The UI update takes another second. Your 3-second wait now has a 500ms margin instead of 2.8 seconds, and on a bad day, it is not enough. The deeper problem is that cy.wait(ms) does not actually wait for anything meaningful. It is a timer, not a condition. It does not know whether the API call finished, whether the DOM updated, or whether the element you need is ready. It just pauses execution for a fixed duration and hopes for the best. Cypress has built-in retry-ability that most developers underuse. Commands like .should(), .contains(), and .find() automatically retry for up to 4 seconds (configurable via defaultCommandTimeout) until the assertion passes. This is genuinely useful and handles many timing issues without any cy.wait() at all. If you chain cy.get('.result').should('contain', 'Success'), Cypress retries the assertion until either the text appears or the timeout expires. But retry-ability has limits. It only works on the last command in a chain. If you write cy.get('.button').click().get('.result').should('contain', 'Success'), the click() is not retried, only the final .should() assertion is. And retry-ability does not help when the issue is a network request that has not completed yet, because Cypress retries DOM queries, not network conditions. The correct fix for network-dependent timing is cy.intercept() combined with cy.wait('@alias'). You register an intercept for the specific API endpoint your action triggers, give it an alias, perform the action, then wait for the aliased request to complete. This ties your test to a real condition (the API responded) rather than an arbitrary timer.

// BAD: arbitrary wait that works locally, flakes in CI
cy.get('[data-testid="submit"]').click();
cy.wait(3000); // hoping the API responds in time
cy.get('[data-testid="success-message"]')
  .should('contain', 'Order placed');

// GOOD: wait for the actual network request to complete
cy.intercept('POST', '/api/orders').as('createOrder');
cy.get('[data-testid="submit"]').click();
cy.wait('@createOrder'); // waits until the POST /api/orders responds
cy.get('[data-testid="success-message"]')
  .should('contain', 'Order placed');

// ALSO GOOD: assert on the response to catch API-level bugs
cy.intercept('POST', '/api/orders').as('createOrder');
cy.get('[data-testid="submit"]').click();
cy.wait('@createOrder').then((interception) => {
  expect(interception.response.statusCode).to.equal(201);
  expect(interception.response.body).to.have.property('orderId');
});
cy.get('[data-testid="success-message"]')
  .should('contain', 'Order placed');

Single-tab and cross-origin limitations

Cypress runs inside the browser alongside your application. This is what makes its developer experience great: time-travel debugging, automatic waiting, and real DOM access. But it also creates hard architectural limits that cause flakiness in specific categories of tests. The single-tab limitation means Cypress cannot natively test flows that open new tabs or windows. When your app calls window.open() for an OAuth callback, a help page, or a print preview, Cypress cannot follow. The test hangs waiting for an interaction in a tab it cannot see. Teams work around this by stubbing window.open() to redirect to the same tab, but this changes the behavior being tested. Your production users get a popup; your test gets an in-tab redirect. Bugs that only appear in the popup flow go undetected. Cross-origin restrictions are the bigger source of flakiness. Before Cypress 12, visiting a different origin mid-test was essentially impossible without setting chromeWebSecurity: false, which disables the browser's same-origin policy entirely. This works, but it means your tests run in a security context that no real user ever experiences. Cypress 12 introduced cy.origin(), which lets you execute commands in a different origin's context. This handles OAuth flows where you need to interact with a Google or GitHub login page, then return to your app. However, cy.origin() has real limitations that cause intermittent failures. It creates a new Cypress command context for the foreign origin, which means local variables, aliases, and hooks from the parent context are not available. Timing between the origin switch and command execution can vary, causing tests to fail when the foreign page loads slowly in CI. Stripe Elements iframes are another common source. Stripe renders payment fields in a cross-origin iframe on js.stripe.com. Cypress cannot interact with cross-origin iframes using standard commands. The cypress-iframe plugin helps but relies on disabling web security, and iframe loading time in CI is unpredictable. Popup-based authentication flows (like "Sign in with Google" buttons that open a popup window) are essentially untestable in Cypress. The popup is a separate browser context that Cypress cannot control. Most teams work around this by using programmatic login via API calls and injecting session tokens, skipping the popup flow entirely in tests. This is pragmatic but means the actual OAuth popup flow is never tested in CI.

// Cypress 12+ cy.origin() for OAuth flows
cy.visit('/login');
cy.get('[data-testid="google-login"]').click();

// Switch to Google's origin to interact with their login page
cy.origin('https://accounts.google.com', () => {
  cy.get('input[type="email"]')
    .should('be.visible')
    .type('[email protected]');
  cy.get('#identifierNext').click();
  cy.get('input[type="password"]')
    .should('be.visible')
    .type('testpassword123');
  cy.get('#passwordNext').click();
});

// Back on your origin after redirect
cy.url().should('include', '/dashboard');

// LIMITATION: cy.origin() does not share aliases or state
// This will NOT work:
cy.intercept('/api/user').as('getUser');
cy.origin('https://accounts.google.com', () => {
  // cy.wait('@getUser') - ERROR: alias not available here
});

// WORKAROUND for Stripe iframes:
// Requires chromeWebSecurity: false in cypress.config.ts
cy.get('iframe[src*="js.stripe.com"]')
  .its('0.contentDocument.body')
  .should('not.be.empty')
  .then(cy.wrap)
  .find('input[name="cardnumber"]')
  .type('4242424242424242');

Cypress Cloud vs DIY flake detection

Cypress Cloud (formerly Cypress Dashboard) offers built-in flaky test analytics starting at $67/month for the Team plan, scaling to $300+/month for Business features. It automatically tags tests that fail on the first attempt but pass on retry, tracks flake rate over time, and surfaces your worst offenders. For teams that can afford it, Cypress Cloud provides real visibility into flake patterns. It is a good product. But many teams cannot justify $67-$300+/month for test analytics alone, especially early-stage teams already paying for CI runners, staging infrastructure, and other dev tools. If that is your situation, you can build basic flake detection yourself. The approach is straightforward. Run your Cypress suite with --retries 1, which tells Cypress to retry each failed test once. Cypress logs which tests failed on the first attempt and which passed on retry. A test that fails then passes on retry is, by definition, flaky. A test that fails on both attempts is likely a real regression. To track this over time, parse Cypress's JSON reporter output after each CI run. The mochawesome reporter produces structured JSON that includes each test's attempts. A simple script can extract tests with multiple attempts, calculate the flake rate per test (failures / total runs), and output a summary. Store the results in a JSON file committed to your repo, a database, or a simple Google Sheet. Over 30 days, you will see which tests flake most and can prioritize fixes. The DIY approach lacks Cypress Cloud's polish. You do not get a dashboard, automatic tagging, or trend visualization. But for teams spending $0 on flake detection today, a 30-line script that runs after each CI build gives you 80% of the value at zero additional cost. One important note: retries themselves mask the problem. A suite with --retries 2 will have a higher pass rate, but the underlying flakiness is unchanged. Use retries for detection and reporting, not as a permanent fix. If a test flakes more than 10% of the time, fix the root cause or delete the test.

// scripts/flake-report.js
// Run after: npx cypress run --retries 1 --reporter mochawesome
const fs = require('fs');
const results = JSON.parse(
  fs.readFileSync('mochawesome-report/mochawesome.json', 'utf8')
);

const flakyTests = [];

function walkSuites(suites) {
  for (const suite of suites) {
    for (const test of suite.tests || []) {
      // A test with >1 attempt that ultimately passed is flaky
      if (test.pass && test.attempts && test.attempts > 1) {
        flakyTests.push({
          title: test.fullTitle,
          file: suite.file,
          attempts: test.attempts,
          duration: test.duration,
        });
      }
    }
    if (suite.suites) walkSuites(suite.suites);
  }
}

walkSuites(results.results);

console.log(`\n=== Flaky Test Report ===`);
console.log(`Total flaky tests: ${flakyTests.length}`);
console.log(`Flake rate: ${(
  (flakyTests.length / results.stats.tests) * 100
).toFixed(1)}%\n`);

for (const t of flakyTests) {
  console.log(`  FLAKY: ${t.title}`);
  console.log(`    File: ${t.file}`);
  console.log(`    Attempts: ${t.attempts}\n`);
}

// Append to historical tracking file
const history = fs.existsSync('flake-history.json')
  ? JSON.parse(fs.readFileSync('flake-history.json', 'utf8'))
  : [];

history.push({
  date: new Date().toISOString(),
  totalTests: results.stats.tests,
  flakyCount: flakyTests.length,
  flakyTests: flakyTests.map((t) => t.title),
});

fs.writeFileSync('flake-history.json', JSON.stringify(history, null, 2));