Cypress gives frontend engineers a superpower: the ability to write E2E tests that watch our app behave just like a real user would. But with great power comes… well, a lot of subtle flakiness if you’re not careful. The cy.wait Illusion: What's Really Happening cy.wait The scenario is simple: you have a component that loads data, and after a user action, it loads new data using the same API endpoint. To ensure the new data has arrived, you intercept the request and then use cy.wait('@requestAlias') multiple times. cy.wait('@requestAlias') // A common, flawed approach:
cy.intercept('GET', '/api/items/*', { fixture: 'item-1' }).as('getItems');
cy.visit('/items');

// 1. Wait for the initial load
cy.wait('@getItems'); 

// ... User performs an action that triggers the SAME request ...

// 2. Wait for the second load
cy.wait('@getItems'); // <-- THIS IS THE PROBLEM // A common, flawed approach:
cy.intercept('GET', '/api/items/*', { fixture: 'item-1' }).as('getItems');
cy.visit('/items');

// 1. Wait for the initial load
cy.wait('@getItems'); 

// ... User performs an action that triggers the SAME request ...

// 2. Wait for the second load
cy.wait('@getItems'); // <-- THIS IS THE PROBLEM The Flaw Cypress's cy.intercept logic is designed to capture a single match for an alias. When you call cy.wait('@getItems') for the first time, it finds the initial request, waits for its resolution, and then the alias is fulfilled. cy.intercept a single match cy.wait('@getItems') fulfilled When you call cy.wait('@getItems') a second time, Cypress does not reset the listener. Instead, it checks if a request has already been resolved with that alias. Because the first request has resolved, the second cy.wait command resolves immediately, without waiting for the new network call to finish. Your test is now racing against the network, not waiting for it. cy.wait('@getItems') already cy.wait resolves immediately, new Fix #1: Re-intercept before each expected request (Works, explicit, but verbose) (Works, explicit, but verbose) cy.intercept('GET', '/api/items').as('getItems_1')
cy.get('[data-testid=refresh]').click()
cy.wait('@getItems_1')

cy.intercept('GET', '/api/items').as('getItems_2')
cy.get('[data-testid=load-more]').click()
cy.wait('@getItems_2') cy.intercept('GET', '/api/items').as('getItems_1')
cy.get('[data-testid=refresh]').click()
cy.wait('@getItems_1')

cy.intercept('GET', '/api/items').as('getItems_2')
cy.get('[data-testid=load-more]').click()
cy.wait('@getItems_2') Clear, deterministic, but repetitive. Fix #2: Use times: 1 to force Cypress to “consume” intercepts times: 1 (Cleaner: Cypress forgets the intercept after one match) (Cleaner: Cypress forgets the intercept after one match) This is the missing tool many engineers don’t realize exists. cy.intercept({
  method: 'GET',
  pathname: '/api/items',
  times: 1
}).as('getItems')

// trigger request 1
cy.get('[data-testid=refresh]').click()
cy.wait('@getItems')

cy.intercept({
  method: 'GET',
  pathname: '/api/items',
  times: 1
}).as('getItems')

// trigger request 2
cy.get('[data-testid=load-more]').click()
cy.wait('@getItems') cy.intercept({
  method: 'GET',
  pathname: '/api/items',
  times: 1
}).as('getItems')

// trigger request 1
cy.get('[data-testid=refresh]').click()
cy.wait('@getItems')

cy.intercept({
  method: 'GET',
  pathname: '/api/items',
  times: 1
}).as('getItems')

// trigger request 2
cy.get('[data-testid=load-more]').click()
cy.wait('@getItems') Why this works: times: 1 means Cypress removes the intercept after a single matching request
Re-declaring the intercept creates a fresh listener
Each cy.wait('@getItems') now truly waits for the next occurrence times: 1 means Cypress removes the intercept after a single matching request times: 1 Re-declaring the intercept creates a fresh listener Each cy.wait('@getItems') now truly waits for the next occurrence cy.wait('@getItems') next This technique gives you explicit, occurrence-specific intercepts without alias clutter. For tests that must assert network behavior (payloads, headers, error flows), it’s a clean and robust pattern. Fix #3: Stop waiting for requests altogether (The best fix. UI > network.) (The best fix. UI > network.) Here’s the golden rule: Users don’t observe network resolution — they observe UI state. Users don’t observe network resolution — they observe UI state. That means the most stable tests assert what the user sees: A loading spinner appears → disappears
A button becomes disabled → enabled
A success message appears when an action is complete.
The newly loaded element is now visible in the DOM. A loading spinner appears → disappears A button becomes disabled → enabled A success message appears when an action is complete. The newly loaded element is now visible in the DOM. Example with user-visible cues: cy.get('[data-testid=refresh]').click()

cy.get('[data-testid=spinner]').should('exist')
cy.get('[data-testid=spinner]').should('not.exist')

cy.get('[data-testid=item-list]')
  .children()
  .should('have.length.at.least', 1) cy.get('[data-testid=refresh]').click()

cy.get('[data-testid=spinner]').should('exist')
cy.get('[data-testid=spinner]').should('not.exist')

cy.get('[data-testid=item-list]')
  .children()
  .should('have.length.at.least', 1) No reliance on internal network timing. No alias lifecycle. Zero flake. Accessibility makes this even more robust Accessible UI patterns make great Cypress hooks: aria-busy attribute aria-busy <ul data-testid="item-list" aria-busy="true"> <ul data-testid="item-list" aria-busy="true"> Test: cy.get('[data-testid=item-list]').should('have.attr', 'aria-busy', 'false') cy.get('[data-testid=item-list]').should('have.attr', 'aria-busy', 'false') role="status" with live regions role="status" <div role="status" aria-live="polite" data-testid="status">
  Loading…
</div> <div role="status" aria-live="polite" data-testid="status">
  Loading…
</div> Test: cy.get('[data-testid=status]').should('contain', 'Loaded 10 items') cy.get('[data-testid=status]').should('contain', 'Loaded 10 items') Disabled states for actions cy.get('[data-testid=submit]').should('be.disabled')
cy.get('[data-testid=submit]').should('not.be.disabled') cy.get('[data-testid=submit]').should('be.disabled')
cy.get('[data-testid=submit]').should('not.be.disabled') These patterns aid screen reader users and produce stable, deterministic E2E tests. and When waiting for requests is appropriate There ARE valid scenarios: Asserting payloads or query params
Mocking backend responses
Validating request ordering
Verifying retry logic
Testing error handling flows Asserting payloads or query params Mocking backend responses Validating request ordering Verifying retry logic Testing error handling flows For those cases: Combine times: 1 with explicit, fresh intercepts defined right before triggers. times: 1 For other cases: the test should rely on the UI state. A combined real-world example (Network + UI, the best of both worlds) (Network + UI, the best of both worlds) // UI-driven loading signal
cy.get('[data-testid=create]').click()
cy.get('[data-testid=spinner]').should('exist')

// Network contract check
cy.intercept({
  method: 'POST',
  pathname: '/api/items',
  times: 1
}).as('postItem')

cy.get('[data-testid=create]').click()
cy.wait('@postItem')
  .its('request.body')
  .should('deep.include', { title: 'New item' })

// Final user-visible assertion
cy.get('[data-testid=status]').should('contain', 'Item created') // UI-driven loading signal
cy.get('[data-testid=create]').click()
cy.get('[data-testid=spinner]').should('exist')

// Network contract check
cy.intercept({
  method: 'POST',
  pathname: '/api/items',
  times: 1
}).as('postItem')

cy.get('[data-testid=create]').click()
cy.wait('@postItem')
  .its('request.body')
  .should('deep.include', { title: 'New item' })

// Final user-visible assertion
cy.get('[data-testid=status]').should('contain', 'Item created') The network part is accurate. The UI part is resilient. The test is rock-solid. Final checklist For accessible, deterministic, non-flaky Cypress tests Prefer user-visible UI state, not network events
Use aria-busy, role="status", aria-live, and disabled states
When waiting for requests:

Re-intercept before each occurrence, OR
Use times: 1 to auto-expire the intercept


Avoid global, long-lived intercepts
Never assume cy.wait('@alias') waits “for the next request”
Make loading and completion states accessible (good for tests, good for users) Prefer user-visible UI state, not network events user-visible UI state Use aria-busy, role="status", aria-live, and disabled states aria-busy role="status" aria-live When waiting for requests:

Re-intercept before each occurrence, OR
Use times: 1 to auto-expire the intercept Re-intercept before each occurrence, OR
Use times: 1 to auto-expire the intercept Re-intercept before each occurrence, OR Use times: 1 to auto-expire the intercept times: 1 Avoid global, long-lived intercepts Never assume cy.wait('@alias') waits “for the next request” cy.wait('@alias') Make loading and completion states accessible (good for tests, good for users)

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Achieving Reliable E2E Tests in Cypress: Overcome cy.wait Pitfalls

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Answer Engine SEO: How to Make Your Website AI-Readable in 2025

20 Hours of Work, $258 in Sales — The First Week of Shade

4 Quick and Easy Tips to Make Your WordPress Website ADA Compliant

4 ways CSS :has() can make your HTML forms even better

5 Resources to Measure Website Accessibility

6 Tips to Host a Successful Virtual Networking Event

Answer Engine SEO: How to Make Your Website AI-Readable in 2025

20 Hours of Work, $258 in Sales — The First Week of Shade

4 Quick and Easy Tips to Make Your WordPress Website ADA Compliant

4 ways CSS :has() can make your HTML forms even better

5 Resources to Measure Website Accessibility

6 Tips to Host a Successful Virtual Networking Event

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps