## 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
```text
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.
```js
// 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.
```js
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.
```js
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.
```js
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/pst_oqRtgOxD_Af3yVd6e2drgw