Cypress.io and CI Parallelization: cy.intercept Stub Resolution Race Conditions

Short Answer

No — Cypress does not guarantee that cy.intercept is active before the first page load in each parallel container. Each container in cypress run --parallel runs an independent Cypress runner with its own command queue, and intercepts are registered as queued commands, not synchronously at spec load. If your application fires a request during cy.visit() before the intercept command has been processed, the request goes to the real backend and you get exactly the symptom you describe: an intermittent 404 with no useful trace.

Likely Explanation vs. Confirmed Facts

Confirmed behavior: intercepts are per-runner and per-test. Nothing is shared across parallel containers, and registration happens in command-queue order as the test executes. An intercept declared after cy.visit() — or in a support file path that runs too late — cannot catch requests the app makes at boot.

Likely explanation for your flakes: under parallel CI, container CPU contention slows command-queue processing, widening the window between page load and stub activation. That's why the same spec passes sequentially and fails only under load.

Fix

Register the intercept before any navigation, in a beforeEach that precedes cy.visit():

beforeEach(() => {
  cy.intercept('GET', '/api/config', { fixture: 'config.json' }).as('getConfig');
  cy.visit('/');
  cy.wait('@getConfig'); // deterministic barrier before interacting
});

The cy.wait('@alias') converts a timing assumption into an assertion: if the stub didn't catch the request, the wait times out loudly instead of producing a silent 404 downstream.

Distinguishing a Deployment 404 from a Stub Race

1. Sequential control: run the failing spec alone with cypress run --spec path/to/spec.cy.js. If the 404 disappears, it's a race, not a missing backend route.
2. Request inspection: in the Cypress command log, click the failing request. Intercepted requests are marked with a stub indicator; a request with no intercept badge that hit the network confirms the stub wasn't active.
3. Assert the alias: add cy.wait('@alias') immediately after the triggering action. A timeout here proves the request bypassed the stub.

Caveats

Don't rely on video/screenshots for this diagnosis — they capture state after the failure. If flakes persist after reordering, check whether the app fires requests from a service worker or before the Cypress-controlled page context, which intercepts cannot see. One detail that would change this recommendation: whether the 404'd request originates from the initial HTML load rather than XHR/fetch — cy.intercept only handles the latter.