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

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

ECONNREFUSED means nothing is listening where Cypress knocked. Start your app before the Cypress run and block until a health endpoint answers. Nine times out of ten the app simply was not up yet, or the port in the URL is wrong.

Error

CypressError: cy.request() failed trying to load:

YOUR_HOST/api/health

We attempted to make an http request to this URL but the request failed without a response.

The request we sent was:

Method: GET
URL: YOUR_HOST/api/health

The error was:

Error: connect ECONNREFUSED YOUR_HOST:3000

Steps

1. From the same machine or container that runs Cypress, curl the health endpoint by hand. Expected: a 200 response, which proves the app is reachable.
2. If step 1 fails, start the app and wait for it before launching Cypress:

npx start-server-and-wait start YOUR_HOST/api/health "npx cypress run"

Expected: the wait command exits only after the health endpoint answers.

3. Check that baseUrl in cypress.config.js uses the same host and port the app actually listens on. Expected: the config URL and the app listen port match exactly.
4. In Docker Compose or multi-container CI, use the service name as the host and add a healthcheck dependency so Cypress starts after the app is ready. Expected: Cypress never starts against a cold container.
5. Re-run the suite. Expected: cy.request() gets responses instead of refusals.

When to use

• cy.request() or cy.visit() fails with ECONNREFUSED
• The suite runs in CI or Docker but works on your machine
• You recently changed the app port, the start command, or the CI job order

When not to use

• The server responds with 4xx or 5xx (the app is up; the request or the app logic is wrong)
• DNS lookup fails (a networking or hostname problem, not a startup-order problem)
• The app crashes during boot (fix the crash first, then come back)

Tool compatibility

• Cypress 12 through 14, cy.request() and cy.visit()
• start-server-and-wait 3.x or the wait-on 7.x package
• Docker Compose, GitHub Actions, CircleCI, Jenkins

Variant phrasings

cy.request failed without a response in docker

Same fix. The Cypress container usually starts before the app container is listening. Wait on the service hostname, not a fixed sleep.

connect ECONNREFUSED in CI only

Compare the CI start command with your local one. CI often skips the dev server step or binds a different port.

Why it happens

Cypress does not start your app for you. Locally the dev server is already running from your terminal, so requests succeed. In CI or a fresh container nothing is listening yet, or the job launches Cypress in parallel with the server, so the TCP connection is refused.

Edge cases

• Health endpoint answers but API calls still refuse: the app listens on one port and the API on another. Point each URL at the right port.
• Works with npm start but not in CI: the CI step may run the server in the background without waiting. Keep the wait step in the same job.
• Intermittent refusals under load: the server is overwhelmed or restarting. Add retries around the health check and check server logs.

Provenance

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

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

Thread query: cy.request() failed with ECONNREFUSED in cypress

TL;DR: ECONNREFUSED means nothing is listening where Cypress knocked. Start your app before the Cypress run and block until a health endpoint answers. Nine times out of ten the app simply was not up yet, or the port in the URL is wrong.

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.