Why can a Cypress `cy.intercept()` route never fire even though the page loads that resource?

## What `cy.intercept()` is watching A route registered with `cy.intercept()` is a **rule applied to requests at the network layer**. It is not a patch over the application's `fetch` or `XMLHttpRequest`, and it is not a subscription to the browser's resource loader. That distinction is invisible most of the time and decisive here: **if the browser never issues a request, no rule can match it.** The browser's HTTP cache is the most common reason a request is never issued. When a weather dashboard's station list comes back with `cache-control: max-age=86400`, or the radar legend image is a fingerprinted asset marked immutable, a later load is answered from memory or disk **inside the browser**. Cypress is never consulted, because there is nothing to consult it about. ## How the failure actually presents The symptom is easy to misread, because the page looks correct — the stations render, the radar draws — while the test insists nothing happened: - The **Routes** instrument panel in the Cypress Command Log shows your route with a match count of **0**. - `cy.wait('@stations')` fails while still waiting for the *request*, not for a slow response. - The failure is **order-dependent**. The first spec in a run passes on a cold cache; the second one fails because the first one warmed it. - The browser's own network panel labels the offending entries as served from cache. Those are precisely the entries an intercept cannot see. - A stub attached to the route (a fixture, a static body) silently has no effect, so the app renders **real** data and an assertion written against the fixture fails on content, not on timing. Raising a timeout never helps. There is no request in flight to wait longer for, so a bigger budget only makes the same failure slower. ## Making the request happen You cannot make `cy.intercept()` reach into the cache, so the fix is always to remove the cache's ability to answer. Three documented approaches, in rough order of preference: 1. **Turn caching off at the source.** Have the API or dev server send `cache-control: no-store` when it is running in test mode. This is the cleanest option because it applies to every browser and every spec, with nothing in the test code. 2. **Strip the caching headers with a top-level Cypress route.** Register a broad route in a `beforeEach` that rewrites `cache-control` on the responses you care about, so the browser has nothing worth storing. 3. **Disable the cache in the browser.** Chromium-family browsers expose this through the browser's remote debugging protocol; it is the heaviest hammer and the least portable across the browsers a suite runs. | Approach | Where it applies | What it costs | |---|---|---| | `no-store` from the dev server | Every browser, every spec | A test-mode branch in server config | | Top-level Cypress route | The specs that register it | An extra route in the matching order | | Disable the cache in the browser | Chromium-family browsers only | Least portable; least production-like | ## The judgement underneath Defeating the cache changes what you are testing. A suite that runs entirely with `no-store` never exercises the caching your users get, so the test environment drifts from production in a way nobody notices until a caching bug ships. Prefer defeating the cache **narrowly** — on the API responses whose content a test asserts — and leave static assets cached, because a test almost never needs to intercept the radar legend. The mirror-image trap is asserting that something *was* served from cache by checking that a route did **not** fire. Zero matches is a weak signal: it is equally consistent with a wrong URL pattern, a route registered too late, and a request the app never made. If caching behaviour itself is the thing under test, drive it with `cy.request()`, which goes through Cypress rather than the browser cache, and assert on the status your server actually returned. ## What to remember - `cy.intercept()` sees requests **at the network layer**; a cache hit never gets there. - Zero matches plus a rendered page is the fingerprint — check the browser's network panel before rewriting the pattern. - Fix it by making the request happen, not by widening the timeout or loosening the matcher. - Defeat the cache narrowly, so the suite still resembles what production serves.