How to Fix cy.intercept Not Working in Cypress

TL;DR

Register cy.intercept before cy.visit, cy.mount, or the click that sends the request. Match the real browser method and URL, trigger the request, and inspect the alias count plus the UI result. cy.request traffic cannot be intercepted.

Key Takeaways

• Register the intercept before the action that can send the request.
• Compare the route matcher with the browser request method, URL, and query.
• Assert on cy.request directly because it does not trigger cy.intercept.
• Check browser cache when a later navigation sends no network request.
• Review route precedence when an alias matches but the wrong response appears.
• Trigger one request per alias wait and use @alias.all to inspect counts.
• Verify the same spec against a reachable CI or Docker base URL.

To fix cy intercept not working in Cypress, start by checking when the browser sends the request. The failure usually appears when cy.wait('@alias') sees no matching application request, even though the page seems to load or DevTools shows traffic. Register the route before the action, then compare its method and URL matcher with the actual request.

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

The alias and timeout in that representative Cypress message change with your test configuration. A route that matches but never receives a response produces a different wait failure. This guide uses a small local app so you can prove each diagnosis before transferring the pattern to a production spec.

TL;DR

Put cy.intercept() before cy.visit(), cy.mount(), or the click that starts the request. Match the real HTTP method and URL, give the route an alias, trigger one browser request, and wait on that alias. Do not expect cy.intercept() to capture cy.request().

cy.intercept('GET', '**/api/items?status=active').as('getItems')
cy.visit('/')
cy.get('#load-items').click()
cy.wait('@getItems').its('response.statusCode').should('eq', 200)

The selector and endpoint above belong to the reproducible app below. If your page requests items during its initial render, leave the intercept before cy.visit() and remove the click. Read Cypress cy.intercept fundamentals for the core spy and stub model, then use this guide to isolate why a particular route is missed.

What the Error Actually Means

cy.intercept() registers a network matcher. cy.wait('@getItems') waits first for a browser request that matches the registered route and then for its response. The displayed "No request ever occurred" means Cypress did not observe a matching request within the request-wait period. It does not prove the server was unreachable or that an API returned a bad status.

Look at the Routes instrument in the Cypress Command Log. Its match count shows whether the alias saw any traffic. A yellow badge on a logged request indicates a match. Open the browser Network panel to inspect the actual method, hostname, pathname, and query string. A request can be visible there yet miss a narrow matcher. Another possibility is that no network request was made at all because the application reused cached data or the expected UI action never ran.

The default requestTimeout and responseTimeout are separate settings. Increasing requestTimeout only delays discovery of a missing or mismatched call. A request seen by the route but stuck before completion belongs to the response side of the diagnosis. The Cypress alias waiting guide explains the timing model in more detail. Cypress's official intercept reference documents matchers, route ordering, caching, and the Routes instrument.

Root-Cause Decision Table

Reproducible Setup

Create demo-server.cjs at the root of a throwaway Cypress project. It uses Node's built-in HTTP server, so no application framework or invented package version is needed. Install Cypress with npm install --save-dev cypress, then check the installed version with npx cypress version. Use a Node release supported by that Cypress version.

// demo-server.cjs
const http = require('node:http')

const html = `<!doctype html><html><body>
<button id="load-items">Load items</button>
<button id="search">Search</button>
<button id="save">Save</button>
<button id="graph">GraphQL</button>
<pre id="output"></pre>
<script>
const output = document.querySelector('#output')
async function show(url, options) {
  const response = await fetch(url, options)
  output.textContent = JSON.stringify(await response.json())
}
document.querySelector('#load-items').onclick = () => show('/api/items?status=active')
document.querySelector('#search').onclick = () => show('/api/search?q=qa')
document.querySelector('#save').onclick = () => show('/api/save', {
  method: 'POST', headers: { 'content-type': 'application/json' },
  body: JSON.stringify({ title: 'draft' })
})
document.querySelector('#graph').onclick = () => show('/api/graphql', {
  method: 'POST', headers: { 'content-type': 'application/json' },
  body: JSON.stringify({ operationName: 'GetItems', query: 'query GetItems { items { id } }' })
})
show('/api/config')
</script></body></html>`

http.createServer((req, res) => {
  const url = new URL(req.url, 'http://127.0.0.1:4177')
  if (url.pathname === '/') {
    res.writeHead(200, { 'content-type': 'text/html' })
    return res.end(html)
  }
  const data = url.pathname === '/api/items' ? { items: [{ id: 1 }] }
    : url.pathname === '/api/config' ? { theme: 'light' }
    : url.pathname === '/api/search' ? { query: url.searchParams.get('q') }
    : url.pathname === '/api/save' ? { saved: true }
    : url.pathname === '/api/graphql' ? { data: { items: [{ id: 1 }] } }
    : null
  if (!data) {
    res.writeHead(404)
    return res.end('Not found')
  }
  res.writeHead(200, {
    'content-type': 'application/json',
    ...(url.pathname === '/api/config' ? { 'cache-control': 'max-age=3600' } : {})
  })
  res.end(JSON.stringify(data))
}).listen(4177, '0.0.0.0', () => console.log('Demo server on 4177'))

In one terminal, run node demo-server.cjs. Verify it with curl -i 'http://127.0.0.1:4177/api/items?status=active'; expect HTTP 200 and an items array. In a second terminal, place each following spec in cypress/e2e/ and run its stated command. Cypress can infer its default configuration for this minimal project; the commands pass baseUrl explicitly. Keep the server running while testing.

1. Fix cy Intercept Not Working in Cypress When Registration Is Late

A page can request configuration while loading, before cy.visit() resolves. Registering the route after cy.visit('/') misses that request. The demo page calls /api/config in its inline script during startup, making the race visible. Moving only cy.wait() earlier cannot help because waiting does not retroactively attach a handler to past traffic.

// cypress/e2e/01-register-first.cy.js
it('captures the startup config request', () => {
  cy.intercept('GET', '**/api/config').as('config')
  cy.visit('/')
  cy.wait('@config').its('response.statusCode').should('eq', 200)
  cy.get('#output').should('contain.text', 'light')
})

Verify with npx cypress run --spec cypress/e2e/01-register-first.cy.js --config baseUrl=http://127.0.0.1:4177. Expect the alias wait and UI assertion to pass. In a component test, the equivalent order is intercept, then cy.mount(<Component />), then wait. A button-driven request allows registration immediately before the click; a mount-time effect requires registration before mount.

For a real application, find the first action that can launch the request. That might be a redirect, an initial render effect, or a route transition, not the obvious button. Keep network capture techniques in Cypress handy when the request's origin is unclear. Put the intercept at the nearest setup point that precedes that first action.

2. Fix cy Intercept Not Working in Cypress When the Matcher Misses

The URL shown by DevTools is authoritative. /api/items does not necessarily match /api/items?status=active under the string pattern you chose, and POST cannot satisfy a GET matcher. Cross-origin calls also introduce a hostname your local shorthand may miss. Start with a broad spy to learn the URL, then replace it with a narrow route matcher that states the contract.

// cypress/e2e/02-match-request.cy.js
it('matches method, pathname, and query', () => {
  cy.intercept({
    method: 'GET',
    pathname: '/api/items',
    query: { status: 'active' }
  }).as('items')
  cy.visit('/')
  cy.get('#load-items').click()
  cy.wait('@items').then(({ request, response }) => {
    expect(request.method).to.eq('GET')
    expect(new URL(request.url).searchParams.get('status')).to.eq('active')
    expect(response.statusCode).to.eq(200)
  })
})

Verify with npx cypress run --spec cypress/e2e/02-match-request.cy.js --config baseUrl=http://127.0.0.1:4177. The URL constructor checks what actually arrived rather than assuming a particular host. If you match a remote API, use a full URL glob such as **/api/items* while diagnosing, then add hostname or pathname once you know the real request. For repeated query parameters, inspect new URL(req.url).searchParams.getAll('ids[]') in a handler; a simple query property does not express every array-style query.

Do not permanently leave a **/* spy in a large suite just to make one test pass. It can collect unrelated assets and conceal an incorrect API contract. The Cypress network stubbing guide covers choosing between observation and a controlled stub.

3. Stop Expecting cy.request() to Trigger an Intercept

cy.request() sends traffic from Cypress's Node process. cy.intercept() observes application traffic from the browser, so the two commands cannot form a request-and-wait pair. This is a common reason the server logs show a request while an intercept's match count remains zero. Use cy.request() to test an endpoint directly, and use a browser action when the question is what the application sent.

// cypress/e2e/03-request-boundary.cy.js
it('asserts a Node request and a separate browser request', () => {
  cy.request('/api/items?status=active')
    .its('body.items').should('have.length', 1)

  cy.intercept('GET', '**/api/items?status=active').as('browserItems')
  cy.visit('/')
  cy.get('#load-items').click()
  cy.wait('@browserItems').its('request.method').should('eq', 'GET')
})

Verify with npx cypress run --spec cypress/e2e/03-request-boundary.cy.js --config baseUrl=http://127.0.0.1:4177. The first assertion checks the real server response; the alias confirms a distinct browser request. Do not infer from cy.request() success that your UI called the API. Conversely, if the UI gets data from a bundled fixture or local state, an intercept wait is the wrong assertion. See cy.request for API testing for the direct-API use case. Cypress's FAQ explicitly describes this process boundary.

4. Remove Cache as a Source of Missing Requests

An HTTP response served from the browser cache does not traverse the network layer, so the intercept has nothing to match. Look in DevTools for a memory-cache or disk-cache response, and compare the first navigation with a reload. This explanation applies to real network responses that the browser cached; Cypress's native interception path can treat internally stubbed responses differently. Avoid making your test depend on whether a prior stub is cached.

The demo server deliberately sends cache-control: max-age=3600 for /api/config. A focused middleware route removes caching from the response before later navigations. It runs first, but does not call req.continue() or req.reply(), so other matching handlers can still participate.

// cypress/e2e/04-cache.cy.js
it('observes configuration on both navigations', () => {
  cy.intercept({ url: '**/api/config', middleware: true }, (req) => {
    req.on('before:response', (res) => {
      res.headers['cache-control'] = 'no-store'
    })
  }).as('config')

  cy.visit('/')
  cy.wait('@config')
  cy.reload()
  cy.wait('@config')
  cy.get('@config.all').should('have.length', 2)
})

Verify with npx cypress run --spec cypress/e2e/04-cache.cy.js --config baseUrl=http://127.0.0.1:4177. The second alias wait demonstrates that a second request was seen. For a product suite, prefer disabling cache headers on the development server in test mode when possible; that keeps a network policy out of individual specs. The official caching section gives the same response-header approach. If a service worker answers requests, inspect its behavior separately before calling the issue an HTTP-cache miss.

5. Resolve Competing Routes and Response Overrides

Several intercepts can match one request. Non-middleware routes run in reverse registration order, while routes with middleware: true run first in their defined order. A later broad stub can therefore override an earlier specific stub. req.reply() ends request handling; req.continue() sends the request upstream and stops remaining request handlers. A passive handler that calls neither can let a later handler participate.

Register shared fallbacks before local overrides. In this example, the broad route is intentionally first, and the specific route is last. The UI shows which response actually won; merely observing an alias wait would miss the wrong stub body.

// cypress/e2e/05-route-order.cy.js
it('uses the test-specific items response', () => {
  cy.intercept('GET', '**/api/items*', { items: [{ id: 'fallback' }] })
  cy.intercept('GET', '**/api/items?status=active', {
    items: [{ id: 'specific' }]
  }).as('specificItems')

  cy.visit('/')
  cy.get('#load-items').click()
  cy.wait('@specificItems').its('response.body.items.0.id')
    .should('eq', 'specific')
  cy.get('#output').should('contain.text', 'specific')
})

Verify with npx cypress run --spec cypress/e2e/05-route-order.cy.js --config baseUrl=http://127.0.0.1:4177. If your shared support file installs a broad intercept after a test's route, inspect the Routes instrument and move the setup or narrow the matcher. Avoid fixing precedence with an arbitrary sleep. Distinguish a route that matched but supplied the wrong response from a route with zero matches; only the latter explains the quoted "No request ever occurred" message.

6. Keep Alias Lifetime and Request Count Aligned

Cypress clears intercepts before each test. An alias created in one it() block is unavailable in another, and a single click does not satisfy two sequential waits. The .all alias form can show how many matching requests occurred, but cy.wait('@items.all') is not its syntax. When a UI automatically retries, count requests deliberately instead of assuming one action means one request.

// cypress/e2e/06-alias-count.cy.js
describe('items requests', () => {
  beforeEach(() => {
    cy.intercept('GET', '**/api/items?status=active').as('items')
    cy.visit('/')
  })

  it('waits once per button click', () => {
    cy.get('#load-items').click()
    cy.wait('@items')
    cy.get('#load-items').click()
    cy.wait('@items')
    cy.get('@items.all').should('have.length', 2)
  })
})

Verify with npx cypress run --spec cypress/e2e/06-alias-count.cy.js --config baseUrl=http://127.0.0.1:4177. If the count is zero, return to registration, matching, or caching. If it is one after two clicks, check whether the UI suppressed a duplicate request or reused application-level data. If the count is two but a response assertion fails, inspect the returned interception rather than adding another wait. For suites with retries and stateful pages, handling flaky Cypress tests gives broader context on keeping each test independent.

7. Match GraphQL Operations Instead of One Shared URL

A GraphQL application may send every query and mutation to /api/graphql. Waiting on a generic POST alias can consume a different operation first, making the expected request appear absent or giving the wrong body. Assign a per-request alias from operationName when that field is present. The demo's GraphQL button sends GetItems, so the alias is stable and does not depend on request ordering with unrelated operations.

// cypress/e2e/07-graphql.cy.js
it('waits for the named GraphQL operation', () => {
  cy.intercept('POST', '**/api/graphql', (req) => {
    if (req.body.operationName === 'GetItems') {
      req.alias = 'getGraphItems'
    }
  })
  cy.visit('/')
  cy.get('#graph').click()
  cy.wait('@getGraphItems').then(({ request, response }) => {
    expect(request.body.operationName).to.eq('GetItems')
    expect(response.body.data.items).to.have.length(1)
  })
})

Verify with npx cypress run --spec cypress/e2e/07-graphql.cy.js --config baseUrl=http://127.0.0.1:4177. If your client omits operationName, inspect req.body.query or a persisted-query identifier and choose a matcher tied to your actual protocol. For batched GraphQL requests, req.body may be an array; handle the array shape explicitly. The principle is to identify the operation you care about, rather than treat all traffic to a common endpoint as equivalent.

8. Fix CI and Docker Base URLs Before Changing Timeouts

A local test can pass while CI points Cypress at a different origin, starts the server too late, or runs a browser with a different cache state. Print the resolved base URL and request URL in the failing job. In the local demo, the server binds to 0.0.0.0, so it can be reached from a container through the appropriate host name. Keep URL matching based on the observed browser request, not the address used by cy.request() on the host.

node demo-server.cjs &
SERVER_PID=$!
trap 'kill "$SERVER_PID"' EXIT
until curl -fsS 'http://127.0.0.1:4177/api/items?status=active' >/dev/null; do sleep 1; done
npx cypress run --spec cypress/e2e/02-match-request.cy.js \
  --config baseUrl=http://127.0.0.1:4177 --browser chrome

Verify the CI variant by running that shell block in an environment with Chrome installed; expect the spec to pass and the server process to exit afterward. If Chrome is unavailable, use the browser provided by your Cypress installation rather than claiming the intercept is broken. On Docker Desktop, host.docker.internal can reach the host server; on Linux, add the host-gateway mapping shown below. Use an image tag that matches your installed Cypress version and a browser present in that image.

docker run --rm --add-host=host.docker.internal:host-gateway \
  -v "$PWD":/e2e -w /e2e --entrypoint cypress \
  cypress/included:<your-cypress-version> run \
  --spec cypress/e2e/02-match-request.cy.js \
  --config baseUrl=http://host.docker.internal:4177

Verify the Docker variant while node demo-server.cjs is running on the host. The demo server's 0.0.0.0 bind is necessary for container access; a process bound only to host loopback may not be reachable. The cypress/included entrypoint is overridden because the command supplies run and its options explicitly. If your CI app is another container on a shared Docker network, use its service name as baseUrl instead. See Cypress environment variables for keeping environment-specific addresses in configuration.

How to Verify the Fix

First run the smallest failing spec, not the full suite. Confirm three separate outcomes: the Routes instrument increments the intended alias count; cy.wait('@alias') yields the expected request.method and request.url; and the page renders the state that the response should produce. An intercept that matches the wrong request can satisfy a wait without validating product behavior.

Run npx cypress run --spec cypress/e2e/01-register-first.cy.js --config baseUrl=http://127.0.0.1:4177 for the startup case. Then run npx cypress run --spec 'cypress/e2e/*.cy.js' --config baseUrl=http://127.0.0.1:4177 to exercise the complete demo. The shell quotes prevent expansion before Cypress receives the glob. If a project has a custom spec pattern, use its configured location instead.

For a real failure, temporarily log the observed request in a broad but scoped handler: cy.intercept('**/api/**', req => console.log(req.method, req.url)). Compare this with the route you intended to match, then remove the diagnostic handler. Avoid printing authorization headers, request bodies, or sensitive query values in CI logs. A passing network assertion and a visible UI assertion together provide stronger evidence than either alone.

Prevent It From Coming Back

Put startup intercepts in beforeEach() before navigation. Keep route patterns near the tests that use them so changes to API paths are reviewed with the UI flow. Match method and pathname when the endpoint is stable; include query or operation name only when it distinguishes the behavior under test. Prefer an explicit cy.wait('@alias') over cy.wait(1000) because the alias identifies what completed.

Review shared support files for broad stubs and response handlers that preempt test-local routes. Keep one test's network state inside that test or its own setup; Cypress clears routes between tests, which helps isolation only when each test registers what it needs. Assert both the request contract and a user-visible result. When server-side caching matters, cover it with a dedicated API or integration test, since the browser cache and Cypress's stubbing path have different observation rules.

In CI, start the app with a readiness check and set a reachable baseUrl for the browser environment. Do not tune requestTimeout until the Routes count and Network panel show that the request is real and simply slow. This keeps a missing request from turning into a longer, less informative failure.

Interview Questions and Answers

Q: Why does cy.wait('@items') say no request ever occurred when DevTools shows one?

The request may precede registration, differ from the method or URL matcher, or be served from cache. I compare the Routes match count with the Network panel and inspect the complete URL. I move the intercept before the triggering action, then assert on the yielded interception.

Q: Can cy.intercept() spy on cy.request()?

No. cy.request() runs through Cypress's Node side, while intercept handles application requests from the browser. I assert on the cy.request() response directly and trigger the UI separately when I need browser traffic evidence.

Q: How do you distinguish a missing request from a slow response?

Cypress waits first for a matching request and then for its response. A zero match count and "No request ever occurred" point to the first phase. A matched route that waits on completion points to the response phase, where I inspect the upstream service or handler.

Q: What happens when two intercepts match the same URL?

Middleware routes run first; other matching routes run in reverse definition order. A reply or continue can end the request phase before another route handles it. I keep shared routes narrow and assert the actual response body, not only the alias.

Q: How do you wait for one GraphQL operation?

I intercept the shared GraphQL endpoint and inspect req.body.operationName. For the intended operation, I set req.alias and wait on that alias. If the client batches operations or omits the name, I adapt to the real payload shape.

Q: What is the cleanest way to diagnose a cache-related miss?

I compare first and later navigations in DevTools and check whether the browser reports a cached response. For tests that need a fresh request, I disable caching on the test server or remove cache headers in a focused response handler. I avoid assuming a stub's cache behavior matches a real server response.

Common Mistakes

• Registering cy.intercept() after cy.visit() when startup code already sent the request.
• Matching an idealized path while the browser sends a different method, host, query, or GraphQL operation.
• Calling cy.request() and then waiting for a browser intercept alias.
• Adding a long cy.wait(1000) or increasing requestTimeout without proving that a matching request exists.
• Waiting twice on one alias after triggering only one request.
• Using cy.wait('@alias.all') instead of cy.get('@alias.all') to inspect all matches.
• Letting a broad shared stub reply before a local route can supply the intended response.
• Treating every second-navigation miss as a Cypress defect without checking browser cache and application state.
• Checking only an alias count while the UI renders the wrong response.

Conclusion

To fix cy intercept not working in Cypress, place the route before the browser action, match the request that actually leaves the browser, and verify the response plus the visible result. The local demo lets you reproduce timing, matching, cache, route-order, and alias-count failures one at a time.

Start with the Routes match count. It tells you whether to investigate a missing request or a matched request with the wrong outcome. Once the smallest spec passes locally, run the same spec against the CI browser and base URL before restoring it to the full suite.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• How to Debug a failing test in VS Code in Cypress (2026)
• How to Fix "Cypress failed to start" and cypress verify Errors
• How to Fix "Playwright Test did not expect test() to be called here"
• How to Fix "The Cypress binary is missing" in CI
• How to Fix Cypress "cy.visit() failed trying to load"
• How to Fix Playwright "Element is not attached to the DOM"