cypress cy.intercept() stubbing the wrong request: how to scope

Not specified by the original author.

TL;DR

The intercept was registered after the request already fired: a race between the test and the application that CI timing exposes. Locally the test code usually wins the race; in CI the app is sometimes faster or the test is sometimes slower, and the request slips past before the interceptor exists. Register cy.intercept() before the action that triggers the request, before cy.visit() or before the click, verify the route matcher, and cy.wait() on the alias.

The query

cypress cy.intercept() could not find a matching request flake in CI  -  timing fix

Use this when

• cy.intercept() could not find a matching request flakes in CI
• the same intercept is rock solid locally
• moving the intercept earlier makes the flake disappear

Not for

• the intercept never matches in any environment (the matcher is wrong; fix the glob)
• the application genuinely does not send the request (an app bug, not a race)
• the flake is in cy.wait('@alias') timing out for a request that is stubbed (check the stub)

Steps

1. Move the intercept above the triggering action

This is the fix in most cases. The interceptor must exist before the request fires, not after.

// before: race
cy.visit('/dashboard');
cy.intercept('GET', '/api/items/**').as('getItems');
// after: deterministic
cy.intercept('GET', '/api/items/**').as('getItems');
cy.visit('/dashboard');
cy.wait('@getUsers');

Expected output: the request is intercepted on every run and the alias wait succeeds.

2. Verify the route matcher against the real request

Open the CI video or the browser devtools recording and compare the actual method and URL against the matcher. A wrong glob fails everywhere; a right glob that flakes is the timing bug.

cy.intercept({ method: 'GET', url: '/api/items/**' }).as('getItems');

Expected output: the matcher demonstrably matches the real request's method and path.

3. Wait on the alias instead of sleeping

Replace any cy.wait(ms) after the action with cy.wait('@alias'). The alias wait retries until the request arrives or the timeout expires.

cy.get('#refresh').click();
cy.wait('@getUsers');
cy.get('[data-testid=user-row]').should('have.length', 3);

Expected output: the test waits exactly as long as the request needs, no more.

4. Handle requests fired on page load

If the app fires the request during initial load, register the intercept in a beforeEach before cy.visit(), so it exists before the page's first byte.

beforeEach(() => {
  cy.intercept('GET', '/api/items/**').as('getItems');
  cy.visit('/dashboard');
});

Expected output: load-time requests are intercepted deterministically in CI.

Tool compatibility

• Cypress 10 - 14
• any browser Cypress supports

Variant phrasings

• cy.intercept() could not find a matching request flake
• cypress intercept timing race CI
• Timed out retrying: cy.wait() never received a matching request

Why it happens

cy.intercept() only catches requests that start after it is registered. Test code and application code race: the test registers the interceptor while the app may already be firing requests. Whichever wins depends on scheduling, and CI's different CPU and network timing flips the winner intermittently. Registering first removes the race entirely.

Edge cases / pitfalls

• apps that fire the request from a service worker or on script parse can beat even an early intercept; stub at the network layer or delay the app boot in tests
• GraphQL apps send every query to one endpoint: match on the operation name in the body, not just the URL
• cy.intercept() with a static response still needs the registration-first ordering; stubbing does not remove the race
• multiple identical requests need times or distinct matchers, or the alias wait may resolve on the wrong one

Provenance

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

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

Thread query: cypress cy.intercept() could not find a matching request flake in CI - timing fix

TL;DR: The intercept was registered after the request already fired: a race between the test and the application that CI timing exposes. Locally the test code usually wins the race; in CI the app is sometimes faster or the test is sometimes slower, and the request slips past before the interceptor exists. Register cy.intercept() before the action that triggers the request, before cy.visit() or before the click, verify the route matcher, and cy.wait() on the alias.

Not specified by the original author.

TL;DR

Use cy.intercept() to stub network responses the app fetches; use cy.stub() for direct function spies. Intercept tests the real request path; stub tests units in isolation.

Error

(Not an error; a technique choice. The confusion: both are called "stubbing".)

Steps

1. If the code under test makes a real HTTP request, use cy.intercept() with a fixture or inline body. Expected: the app's fetch path exercised.
2. If testing a callback or method directly, use cy.stub() / sinon.stub(). Expected: unit-level control.
3. Do not stub what you can intercept: intercept keeps more of the real stack. Expected: higher-fidelity tests.
4. Do not intercept what should be a contract test: over-mocked e2e hides backend drift. Expected: a few unmocked paths remain.
5. Document which tests mock what in the test name or comment. Expected: future readers know the fidelity.

When to use

• Deciding mock strategy for a test.
• Reviewing over-mocked suites.

When not to use

• You need full-stack confidence (use real backend for some tests).
• Playwright (use page.route).

Tool compatibility

• Cypress 10 through 14; cy.intercept, sinon stubs.

Variant phrasings

Cypress stub API response

Usually means intercept; use the network-level tool.

cy.intercept vs cy.stub

The comparison; network vs function.

Why it happens

Both fake dependencies but at different layers. Choosing the wrong layer either over-isolates or under-controls.

Edge cases

• cy.intercept() cannot stub non-network calls; that is what cy.stub() is for.
• Stubbing window.fetch directly fights with intercept; pick one.
• GraphQL needs body-based matching in intercept.

Provenance

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

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

Thread query: cypress intercept vs stub: when to use each

TL;DR: Use cy.intercept() to stub network responses the app fetches; use cy.stub() for direct function spies. Intercept tests the real request path; stub tests units in isolation.

Not specified by the original author.

TL;DR

An intercept that never matches is almost always a pattern problem: wrong method, wrong path, or the request going to a different host. Log the actual requests in the Cypress network tab, copy the real method and URL, and match the pattern to reality.

Error

CypressError: Timed out retrying after 5000ms: `cy.wait()` timed out waiting 5000ms for the 1st request to the route: `getItems`. No request ever occurred.

Steps

1. Open the failing run and look at the Cypress command log network entries (or the browser devtools in headed mode). Expected: you see the real requests the app made.
2. Compare method, path, and query string against your intercept. The most common miss is cy.intercept('GET', '/api/items') when the app calls /api/v2/items?limit=20. Expected: you spot the mismatch.
3. Fix the pattern with a glob or regex: cy.intercept('GET', '/api/**/items*'). Expected: the pattern matches the real request shape.
4. Define the intercept BEFORE the action that triggers the request. Expected: cy.intercept(...) appears above the cy.visit() or click in the test.
5. Re-run and confirm cy.wait('@getItems') resolves with the intercepted request visible in the log. Expected: the wait completes in well under the timeout.

When to use

• cy.wait('@alias') times out with "No request ever occurred".
• You added or changed an intercept and the test broke.

When not to use

• The request fires but the stubbed response is wrong (check the StaticResponse, not the pattern).
• GraphQL requests that batch multiple operations into one call (match on operation name in the body).

Tool compatibility

• Cypress 10 through 14; cy.intercept replaced cy.route in Cypress 6+.

Variant phrasings

No request ever occurred for route

The pattern matched zero requests; the app either did not call it or called a different URL.

cy.wait() timed out waiting for the 1st request

Same failure from the wait side; debug the intercept pattern first.

Why it happens

Intercepts match on method plus a minimatch URL pattern. Apps change endpoints, add version prefixes, or append query params, and the old pattern silently stops matching.

Edge cases

• cy.intercept() does not catch fetch calls made before the intercept was registered; order matters.
• Requests to a different origin need the full URL in the pattern, not just the path.
• GraphQL: match with a function on req.body.operationName instead of the URL.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_r4zVElJv-4bp5KCRiNkTJA

Resolved from the public thread: https://vectle.com/posts/pst_r4zVElJv-4bp5KCRiNkTJA

Thread query: cypress intercept not matching requests: debugging

TL;DR: An intercept that never matches is almost always a pattern problem: wrong method, wrong path, or the request going to a different host. Log the actual requests in the Cypress network tab, copy the real method and URL, and match the pattern to reality.