Cypress · Browser testing end to end

How do you diagnose and fix flaky Cypress tests?

HardflakinessreliabilityracesUpdated Oct 2026
Quiz this track

Short answer

Find the shared or timing-dependent state behind the flake. Replace arbitrary waits with intercepts or retrying assertions, isolate data per test, and remove order dependence rather than retrying the test.

A flaky test passes and fails without a code change. That usually means the test depends on something it does not control: a request that may or may not finish, data left by another test, an animation, or a selector that matches more than one element. The fix is to make the dependency explicit.

Common root causes

  • Fixed waits that are too short on slow machines
  • Requests that race with the assertion
  • Shared database records created by another test
  • Selectors that match multiple elements and depend on order
  • Animations or transitions that intercept a click
  • Time, locale or random data that differs between runs
  • Order dependence hidden by a single passing run
ts
beforeEach(() => {
  cy.intercept("GET", "/api/orders").as("getOrders");
  cy.visit("/orders");
  cy.wait("@getOrders");
});

it("shows the empty state", () => {
  cy.intercept("GET", "/api/orders", []);
  cy.reload();
  cy.get("[data-cy=empty]").should("be.visible");
});
Waiting for the actual request removes the race that caused the empty state to be checked too early.

Reproduce the failure before changing anything. Run the spec repeatedly, run it alone and with the full suite, and check whether the failure follows a specific test. Cypress can retry tests in run mode, but retries are a signal, not a cure. A test that only passes on the second attempt is still broken.

Do not add force, longer timeouts or test retries as the first response. They can hide the race and make the suite slower while leaving the underlying defect in place.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How do you tell whether a flake is caused by shared data?
  2. 2Why are test retries not a fix?
  3. 3How do you handle animation-related flakes?
  4. 4What is the role of test isolation in flakiness?

Say it in the interview

I treat flakiness as an uncontrolled dependency. I reproduce it by running the spec alone and in the full suite, then look for races, shared data, ambiguous selectors or time-dependent values. I replace fixed waits with intercepts or retrying assertions and isolate data per test. Test retries can tell me a test is flaky, but I do not use them as the fix.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Cypress mock interview and get scored feedback on depth, clarity and confidence.