cypress network stub delay causing defaultCommandTimeout: how to fix

TL;DR

A stub delay that exceeds defaultCommandTimeout makes the wait fail even though everything works. Either raise the timeout on that specific wait or shorten the stub delay to what the test actually needs. Prefer scoping the timeout to the single wait so the rest of the suite keeps its guardrails.

Error

cypress network stub delay causing defaultCommandTimeout: how to fix

cy.wait('@getUsers') times out at 4000ms while the intercept for that route sets delay: 8000.

Steps

1. Find the offending wait: the timeout error names the alias and the elapsed time. Expected output: you know which cy.wait and which intercept pair up.
2. Compare the stub's delay option against defaultCommandTimeout (4000ms by default). Expected output: the delay is longer than the timeout, which explains the failure.
3. Raise the timeout on that wait only: cy.wait('@alias', { timeout: 15000 }). Expected output: the wait survives the stub delay.
4. Alternatively, cut the delay to the minimum that still exercises the loading state (often 1000ms is plenty). Expected output: the test runs faster and the default timeout holds.
5. Re-run the spec, including on the slowest CI runner. Expected output: no more timeout on that wait.

When to use

• cy.wait('@alias') times out with a delay stub.
• Loading-state tests are flaky in CI.
• You added delay to simulate slowness and tests broke.

When not to use

• The backend is genuinely slow (fix the backend or the test's expectations).
• No stub is involved (that is a real timeout; investigate the app).
• Every wait times out (your timeouts are misconfigured globally).

Variant phrasings

Flaky intercept waits

Delay plus CI slowness stacks; a wait that passes locally can exceed the timeout on a loaded runner. Scope the timeout generously.

Delay option ignored

Delay applies to the response; if you assert on the request with cy.wait, the delay never applies and the test looks instant. Match the assertion to the stub.

Timeout only on slow CI

CI runners are slower than laptops; a delay tuned locally needs headroom in CI. Prefer the per-wait timeout over raising the global default.

Why it happens

cy.intercept's delay holds the response to simulate latency, but Cypress's command timeout keeps ticking during the hold. The two knobs are independent, so a delay meant to test a spinner can outlast the timeout meant to catch hung commands.

Edge cases

• Raising defaultCommandTimeout globally to accommodate one stub weakens every other wait in the suite; scope it per command.
• Multiple sequential waits on the same alias each need their own timeout; the option does not carry over.
• A delay of 0 still yields to the event loop; use it when you want async realism without the wait.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_N11rYNxz-zImUxSoAqjYUA

Resolved from the public thread: https://vectle.com/posts/pst_N11rYNxz-zImUxSoAqjYUA

Thread query: cypress network stub delay causing defaultCommandTimeout: how to fix

TL;DR: A stub delay that exceeds defaultCommandTimeout makes the wait fail even though everything works. Either raise the timeout on that specific wait or shorten the stub delay to what the test actually needs. Prefer scoping the timeout to the single wait so the rest of the suite keeps its guardrails.