cypress test fails with cy.get() timed out retrying

Not specified by the original author.

TL;DR

cy.get() times out when the selector never matches within the default timeout. First check the selector actually exists in the DOM at that moment, then decide whether the fix is a better selector, a longer timeout, or waiting on the right condition (network idle, element actionable) instead of a fixed wait.

Error

CypressError: Timed out retrying after 4000ms: Expected to find element: `[data-cy=submit]`, but never found it.

Steps

1. Open the Cypress runner and click the failed cy.get() command to see the DOM snapshot at failure time. Expected: you see the page state when the assertion ran.
2. In the browser console of the snapshot, run document.querySelector('[data-cy=submit]'). Expected: null means the selector is wrong or the element renders later; an element means a timing issue.
3. If the selector is wrong, switch to a stable attribute (data-testid, data-cy) instead of classes or structure. Expected: the query returns exactly one element.
4. If the element renders late (after an API call), replace the get with an intercept wait: cy.intercept('GET', '/api/items').as('items'); cy.wait('@items') before the get. Expected: test waits for data, not a fixed time.
5. If the element is genuinely slow, raise the timeout on that command only: cy.get('[data-cy=submit]', { timeout: 10000 }). Expected: command retries up to 10s instead of 4s.

When to use

• The failure message is Timed out retrying on cy.get(), cy.contains(), or cy.find().
• The test passes sometimes and fails others (timing), or fails consistently (selector).
• You can reproduce locally in the Cypress interactive runner.

When not to use

• The timeout is on cy.visit() (server never responded; different cause).
• The error is element is detached from the DOM (re-render race; see that skill).
• You are using Playwright or Selenium (different retry model).

Tool compatibility

• Cypress 10 through 14, any browser Cypress supports.
• Applies to cy.get, cy.contains, cy.find, cy.get().should() chains.

Variant phrasings

Timed out retrying after 4000ms

The default timeout is 4000ms, configurable per command or globally via defaultCommandTimeout.

Expected to find element but never found it

Same root pattern: selector evaluated repeatedly against a DOM that never contained a match.

Why it happens

Cypress retries the query until the timeout, then fails. The usual causes are a selector that does not match anything (typo, dynamic class, wrong attribute), an element that appears only after async work the test did not wait for, or a page that navigated away before the query resolved.

Edge cases

• cy.get() inside a .then() callback does not retry the way top-level commands do; restructure to keep queries at the top level.
• Increasing the global timeout masks slow pages; prefer targeted { timeout } on the slow command.
• Elements inside iframes are invisible to cy.get() without the iframe plugin; a timeout there means a scoping problem, not a missing element.

Provenance

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

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

Thread query: cypress test fails with cy.get() timed out retrying

TL;DR: cy.get() times out when the selector never matches within the default timeout. First check the selector actually exists in the DOM at that moment, then decide whether the fix is a better selector, a longer timeout, or waiting on the right condition (network idle, element actionable) instead of a fixed wait.

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.

Not specified by the original author.

TL;DR

Raise defaultCommandTimeout in your CI config and wait on network requests instead of the clock. CI runners are slower and shared, so elements that appear in a second locally can take several seconds there. A timeout that only happens in CI is almost always an optimistic wait, not a broken test.

Error

CypressError: Timed out retrying after 4000ms: Expected to find element: `.submit-btn`, but never found it.

Steps

1. Run the failing spec locally three times in a row. Expected: green all three times, which confirms the failure is CI-only.
2. Replace fragile selectors with stable data attributes, for example cy.get('[data-cy=submit]'). Expected: the selector matches exactly one element and does not depend on CSS classes or copy.
3. In cypress.config.js, raise the retry timeout:

module.exports = {
  e2e: {
    defaultCommandTimeout: 10000,
  },
}

Expected: the config loads and the new value appears in the Cypress settings panel.

4. If the element renders after an API call, wait on the request instead of guessing:

cy.intercept('GET', '/api/orders').as('orders')
cy.visit('/orders')
cy.wait('@orders')
cy.get('[data-cy=order-row]').should('have.length', 3)

Expected: the test proceeds when the response arrives, with no fixed sleep.

5. Delete any cy.wait(2000) style fixed sleeps in the spec. Expected: no hard-coded sleeps remain.
6. Re-run the spec in CI. Expected: green.

When to use

• cy.get() or cy.contains() times out in CI but passes on your machine
• Failures cluster on specs that render after API responses
• The suite recently gained selectors tied to animations or lazy loading

When not to use

• The timeout also fails locally (fix the selector or the app instead)
• Every spec fails in CI (check baseUrl, services, and the Cypress binary install)
• The failure is a real assertion mismatch rather than a missing element

Tool compatibility

• Cypress 12 through 14, end-to-end testing
• Any CI provider that runs cypress run, including GitHub Actions, CircleCI, and Jenkins
• Chrome, Edge, Firefox, and Electron runners

Variant phrasings

Timed out retrying after 4000ms in GitHub Actions only

Same fix. Shared Actions runners are slow, so the 4 second default is the first thing to raise.

Element never found in the Jenkins pipeline but fine locally

Check whether Jenkins serves a different baseUrl or an older build. If the page itself differs, no timeout will help.

Why it happens

Cypress retries cy.get() until defaultCommandTimeout expires. Local machines are fast and warm. CI runners are cold, shared, and often throttled, so rendering and API responses land later. A selector that needs five seconds in CI fails at the four second default while passing locally in one.

Edge cases

• Still red after raising the timeout to 15000ms: the element genuinely never renders in CI. Check baseUrl, feature flags, and seeded test data.
• Flaky in only one CI browser: browser-specific rendering or animation timing. Scope the timeout change to that browser config.
• Passes alone in CI but fails in the full suite: test pollution. Check testIsolation and state shared between specs.

Provenance

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

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

Thread query: cypress cy.get() timeout in CI only

TL;DR: Raise defaultCommandTimeout in your CI config and wait on network requests instead of the clock. CI runners are slower and shared, so elements that appear in a second locally can take several seconds there. A timeout that only happens in CI is almost always an optimistic wait, not a broken test.