cypress test retries exhausted but passes locally

Not specified by the original author.

TL;DR

Passing locally and failing in CI after retries usually means the test depends on state or timing that differs between the two. Run the spec alone and in suite order, then hunt for shared state. Retries mask flakiness; they do not fix it.

Error

Running: specs/checkout.cy.js
  checkout flow
    1) completes a purchase
    2) completes a purchase
    3) completes a purchase

  0 passing
  3 failing

The test failed after 2 retries and will not be retried again.

Steps

1. Run only the failing spec locally with the same retry settings as CI. Expected: this tells you whether the spec alone is flaky or only fails in suite order.
2. Run the full suite locally in the same order CI uses. Expected: if it fails here too, the cause is order dependence, not the CI machine.
3. Look for state shared between tests: database rows, localStorage, files on disk, or a logged-in session leaking across specs. Expected: you can name the shared state.
4. Seed the data each test needs inside a beforeEach hook instead of relying on a previous spec:

beforeEach(function() {
  cy.task('db:seed')
  cy.visit('/checkout')
})

Expected: every test starts from the same known state.

5. Confirm testIsolation is true (the Cypress 12 default) so page state resets between tests, and move any cross-test setup into cy.session(). Expected: no test depends on another test's leftovers.
6. Re-run in CI. Expected: green on the first attempt, not just after retries.

When to use

• A spec passes locally but burns through retries in CI
• The failure moves between tests from run to run
• The suite recently grew past a handful of specs

When not to use

• The test also fails locally (debug it locally first; CI adds nothing)
• The test caught a real bug (fix the app, not the test)
• You only want to change retry counts (see the retries config docs instead)

Tool compatibility

• Cypress 12 through 14, testIsolation and cy.session()
• retries config in cypress.config.js or per-spec
• Any CI provider; the pattern is provider-independent

Variant phrasings

Test retries exhausted in CI pipeline

Same debugging path. Start by reproducing the order locally before touching timeouts.

Flaky test passes on retry locally but never in CI

Local retries can hide a timing assumption that CI always violates. Remove the retry crutch and fix the wait.

Why it happens

Local runs are often a single warm spec with leftover state that happens to help. CI runs the whole suite cold, in order, on a slower box. Tests that read state written by an earlier test, or that assume fast responses, pass by luck locally and fail honestly in CI.

Edge cases

• Fails in CI even run alone: the difference is the environment, not order. Check baseUrl, seed data, and third-party services in CI.
• Passes in CI sometimes: true timing flake. Replace fixed waits with request or DOM waits.
• Only fails on the first CI run of the day: stale or missing seed data. Make seeding part of the job, not a manual step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k0U5rGNrRzGMlpCaCaKFrA

Resolved from the public thread: https://vectle.com/posts/pst_k0U5rGNrRzGMlpCaCaKFrA

Thread query: cypress test retries exhausted but passes locally

TL;DR: Passing locally and failing in CI after retries usually means the test depends on state or timing that differs between the two. Run the spec alone and in suite order, then hunt for shared state. Retries mask flakiness; they do not fix it.

Not specified by the original author.

TL;DR

CI-only failures come from environment differences, not from the tests being wrong. Diff the environments systematically: base URL, test data, parallelism, viewport, and browser version, then reproduce the CI conditions locally with the same container image.

Error

Cypress run exits with code 1 in CI; the same spec passes with `cypress open` locally.
(No single error string; the failing spec varies run to run.)

Steps

1. Run the exact CI command locally, including the same browser in headless mode: npx cypress run --browser chrome. Expected: reproduces some CI-only failures immediately.
2. Run inside the CI container image locally with docker. Expected: eliminates "works on my machine" environment drift.
3. Check for parallelism issues: run the failing spec alone in CI (--spec). Expected: if it passes alone, the cause is cross-spec interference (shared DB, ports, files).
4. Compare test data URIs CI often seeds a different dataset. Dump the seed counts in both environments. Expected: row counts match; if not, the seed step differs.
5. Check the browser version Cypress used in CI logs versus local. Expected: identical major versions; a mismatch explains rendering and timing differences.

When to use

• Green locally, red in CI, with no code change between the two.
• Failures move between specs from run to run.

When not to use

• The failure reproduces locally (debug it locally; faster).
• CI fails at install or verify time (environment setup issue).

Tool compatibility

• Cypress 10 through 14; any CI provider; docker for local reproduction.

Variant phrasings

Cypress passes headed but fails headless

Headless rendering and timing differ; treat as an environment difference, not a test bug.

Cypress fails only with --record --parallel

Parallel runners share state; look for cross-spec interference.

Why it happens

Local and CI differ in CPU count, memory, screen size, fonts, timezone, seeded data, and network speed. Tests that depend on any of these implicitly fail only where the assumption breaks.

Edge cases

• Timezone differences break date-sensitive tests; pin TZ in CI and locally.
• Font rendering differs between macOS and Linux CI; visual tests need platform-specific baselines.
• CI machines are slower; timeouts tuned on a fast laptop fail under load. Tune timeouts on CI timings.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_r5dxXCMTrHOGHfCBSOXbHA

Resolved from the public thread: https://vectle.com/posts/pst_r5dxXCMTrHOGHfCBSOXbHA

Thread query: cypress run exits with code 1 but tests pass locally

TL;DR: CI-only failures come from environment differences, not from the tests being wrong. Diff the environments systematically: base URL, test data, parallelism, viewport, and browser version, then reproduce the CI conditions locally with the same container image.

Not specified by the original author.

TL;DR

Every Cypress timeout is the same question: what was Cypress waiting for, and why did it never happen? Read the command log to see the last assertion state, fix the underlying wait (selector, network, or app state), and only then consider raising the timeout.

Error

AssertionError: Timed out retrying after 4000ms: expected '[div]' to have text 'Saved', but the text was 'Saving…'

Steps

1. Click the failed command in the runner and read the snapshots: what did the app show at each retry? Expected: you see whether the app was stuck or just slow.
2. Check whether the app reached the expected state at all. If the text stayed Saving…, the bug is in the app or the API it calls, not the test. Expected: a decision between fixing the app and fixing the test.
3. If the app was merely slow, wait on the cause: cy.intercept('POST', '/api/save').as('save') then cy.wait('@save') before asserting. Expected: the test tracks the real completion signal.
4. If the state depends on polling, raise the timeout for that assertion only: .should('have.text', 'Saved', { timeout: 15000 }). Expected: slow-but-correct flows pass without slowing the whole suite.
5. Re-run the spec three times. Expected: three greens before calling it fixed.

When to use

• Any Timed out retrying on assertions, gets, or actions.
• You need a systematic approach rather than guessing.

When not to use

• cy.visit() timeouts (server never responded).
• Timeouts in Playwright, Jest, or Mocha (different retry semantics).

Tool compatibility

• Cypress 10 through 14; per-command { timeout } on queries and assertions.

Variant phrasings

Timed out retrying after 10000ms

Same pattern with a custom timeout; the diagnosis steps are identical.

expected X but the value was Y at timeout

The assertion kept evaluating and never matched; read the last-seen value as the clue.

Why it happens

Cypress retries until the timeout. A timeout means the condition never became true in the window: wrong expectation, slow dependency, or a genuinely broken app state.

Edge cases

• Raising the global defaultCommandTimeout hides performance regressions; keep it at 4s and override per command.
• .should() with a callback retries the whole callback; side effects inside callbacks run multiple times.
• Timeouts on cy.wait('@alias') mean the request never fired; check the intercept pattern, not the timeout.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v-RkCjYEt66LMhRoUKUlhw

Resolved from the public thread: https://vectle.com/posts/pst_v-RkCjYEt66LMhRoUKUlhw

Thread query: Timed out retrying after 4000ms in Cypress: how to fix

TL;DR: Every Cypress timeout is the same question: what was Cypress waiting for, and why did it never happen? Read the command log to see the last assertion state, fix the underlying wait (selector, network, or app state), and only then consider raising the timeout.