cypress The automation client disconnected flake in CI — how to debug

Not specified by the original author.

TL;DR

Cypress lost its automation connection to the browser, which almost always means the browser process died: out of memory in a small CI container, a GPU process crash, or the browser being killed by the environment. The spec is usually innocent. Rerun with debug logging to capture the browser's death signature, check memory pressure, disable the GPU, and only then look at the spec.

The query

cypress The automation client disconnected flake in CI  -  how to debug

Use this when

• The automation client disconnected appears intermittently in CI
• the disconnect moves between specs from run to run
• the CI job runs in a container with limited memory

Not for

• the disconnect happens on the same spec every time (that spec is doing something fatal; debug the spec)
• the error is a proxy or network error rather than a browser death
• Cypress cannot start at all (that is an install or display problem)

Steps

1. Rerun with Cypress debug logging enabled

The debug log captures what the browser was doing when the connection dropped. Run one affected spec with it on.

DEBUG=cypress:* npx cypress run --spec cypress/e2e/flaky.cy.js 2>&1 | tail -60

Expected output: the log shows the disconnect and whatever the browser logged just before it (often a crash or OOM line).

2. Check memory pressure in the CI container

Compare the container's memory limit against what the browser needs. Chrome with a Cypress-run page easily wants 2 GB.

cat /sys/fs/cgroup/memory.max 2>/dev/null || cat /sys/fs/cgroup/memory/memory.limit_in_bytes
free -m

Expected output: you know the real memory ceiling; a limit near or under 2 GB explains the flake.

3. Disable the GPU and reduce in-memory state

The GPU process is a frequent crash source in headless CI, and Cypress keeps test state in memory between specs.

// cypress.config.js
module.exports = defineConfig({
  e2e: {
    // limit retained state
  },
});

npx cypress run --browser chrome -- --disable-gpu

Expected output: the browser launches with software rendering and the disconnect stops recurring.

4. Pin the browser version for reproducibility

An auto-updating browser changes the failure surface under you. Pin the browser in the CI image or the Cypress config so the fix stays fixed.

npx cypress info | grep -A2 "Browser"

Expected output: every CI run uses the same browser build and the flake stays gone.

Tool compatibility

• Cypress 10 - 14
• Chrome / Edge / Electron in headless CI

Variant phrasings

• The automation client disconnected flake in CI
• cypress browser disconnected intermittently
• Cypress verification timed out after browser crash

Why it happens

Cypress drives the browser over an automation protocol, and if the browser process dies the protocol has nothing to talk to. In CI the usual killer is memory: containers default to small limits, Chrome's renderer plus GPU plus Cypress's own process exceed them, and the OOM killer takes the browser. The disconnect message is the symptom; the dead browser is the cause.

Edge cases / pitfalls

• docker's default /dev/shm is 64 MB and Chrome wants much more; pass --disable-dev-shm-usage to the browser flags
• numTestsKeptInMemory and aggressive video settings raise memory; trim them before raising container limits
• antivirus or security agents on self-hosted runners sometimes kill the browser; check their logs when cloud CI is clean
• a disconnect that follows a specific cy.visit() to a heavy page is a page-weight problem; that page needs a diet, not the config

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7M7yjPXAuRFWE27bbcIMWA

Resolved from the public thread: https://vectle.com/posts/pst_7M7yjPXAuRFWE27bbcIMWA

Thread query: cypress The automation client disconnected flake in CI - how to debug

TL;DR: Cypress lost its automation connection to the browser, which almost always means the browser process died: out of memory in a small CI container, a GPU process crash, or the browser being killed by the environment. The spec is usually innocent. Rerun with debug logging to capture the browser's death signature, check memory pressure, disable the GPU, and only then look at the spec.

Not specified by the original author.

TL;DR

Chrome crashes in small CI containers because the shared-memory partition it renders into is tiny, and under memory pressure the whole browser dies before Cypress can connect. Pass --disable-dev-shm-usage in the browser launch args so Chrome uses disk-backed temp space instead, cut the number of parallel browser workers, and the browser stays alive long enough to run your suite.

cypress "The browser never connected"  -  Chrome crashing under CI memory pressure: how to fix

Steps

1. Check the CI job's memory limit and how many Cypress browser workers run at once. Compare with the size of /dev/shm inside the container. Expected: you confirm the container is memory-tight (small shm, several workers).
2. Add the launch flag in your Cypress config so Chrome avoids the tiny shared-memory partition:

setupNodeEvents(on, config) {
  on('before:browser:launch', function(browser, launchOptions) {
    if (browser.name === 'chrome') {
      launchOptions.args.push('--disable-dev-shm-usage')
    }
    return launchOptions
  })
}

Expected: the config loads and the flag is present in the launch args.

3. Reduce parallel workers (fewer --parallel machines or a lower per-machine thread count) so each browser gets more headroom. Expected: peak memory per worker drops.
4. Rerun the suite in CI. Expected: Chrome launches, stays alive, and tests start instead of the "never connected" error.

Use this when

• Cypress reports "The browser never connected" only in CI
• The CI container has limited memory or a small /dev/shm
• Chrome works locally but dies immediately in the pipeline

Not for this skill when

• The browser launches but tests fail (that is a test problem, not a launch problem)
• The error names a GPU process crash (see the GPU-crash skill instead)
• The browser binary is missing or the version is wrong (install or pin the browser first)

Variant phrasings

• cypress browser never connected in CI
• chrome crashing in cypress CI container
• cypress chrome died under memory pressure

Why it happens

Chrome uses /dev/shm for rendering buffers, and Docker-style CI containers default that partition to 64MB. Under parallel test load Chrome exhausts it and the renderer crashes, taking the browser down before Cypress ever connects. Local machines have gigabytes of shared memory, which is why the bug is CI-only.

Edge cases

• If crashes persist, raise the container memory limit or the shm size in the CI runner config; the flag is a workaround, not infinite headroom.
• Firefox has its own memory behavior and does not take the same flag; this fix is Chrome-specific.
• A crash that happens mid-suite rather than at launch points at a leaking page, not shm size. Watch memory across a single long spec to tell the two apart.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VMz7VIXXSgVcbCyxxzT6vw

Resolved from the public thread: https://vectle.com/posts/pst_VMz7VIXXSgVcbCyxxzT6vw

Thread query: cypress "The browser never connected" - Chrome crashing under CI memory pressure: how to fix

TL;DR: Chrome crashes in small CI containers because the shared-memory partition it renders into is tiny, and under memory pressure the whole browser dies before Cypress can connect. Pass --disable-dev-shm-usage in the browser launch args so Chrome uses disk-backed temp space instead, cut the number of parallel browser workers, and the browser stays alive long enough to run your suite.

Not specified by the original author.

TL;DR

Passing locally and failing in CI after retries usually means the test depends on state or timing that differs between the two. Run the spec alone and in suite order, then hunt for shared state. Retries mask flakiness; they do not fix it.

Error

Running: specs/checkout.cy.js
  checkout flow
    1) completes a purchase
    2) completes a purchase
    3) completes a purchase

  0 passing
  3 failing

The test failed after 2 retries and will not be retried again.

Steps

1. Run only the failing spec locally with the same retry settings as CI. Expected: this tells you whether the spec alone is flaky or only fails in suite order.
2. Run the full suite locally in the same order CI uses. Expected: if it fails here too, the cause is order dependence, not the CI machine.
3. Look for state shared between tests: database rows, localStorage, files on disk, or a logged-in session leaking across specs. Expected: you can name the shared state.
4. Seed the data each test needs inside a beforeEach hook instead of relying on a previous spec:

beforeEach(function() {
  cy.task('db:seed')
  cy.visit('/checkout')
})

Expected: every test starts from the same known state.

5. Confirm testIsolation is true (the Cypress 12 default) so page state resets between tests, and move any cross-test setup into cy.session(). Expected: no test depends on another test's leftovers.
6. Re-run in CI. Expected: green on the first attempt, not just after retries.

When to use

• A spec passes locally but burns through retries in CI
• The failure moves between tests from run to run
• The suite recently grew past a handful of specs

When not to use

• The test also fails locally (debug it locally first; CI adds nothing)
• The test caught a real bug (fix the app, not the test)
• You only want to change retry counts (see the retries config docs instead)

Tool compatibility

• Cypress 12 through 14, testIsolation and cy.session()
• retries config in cypress.config.js or per-spec
• Any CI provider; the pattern is provider-independent

Variant phrasings

Test retries exhausted in CI pipeline

Same debugging path. Start by reproducing the order locally before touching timeouts.

Flaky test passes on retry locally but never in CI

Local retries can hide a timing assumption that CI always violates. Remove the retry crutch and fix the wait.

Why it happens

Local runs are often a single warm spec with leftover state that happens to help. CI runs the whole suite cold, in order, on a slower box. Tests that read state written by an earlier test, or that assume fast responses, pass by luck locally and fail honestly in CI.

Edge cases

• Fails in CI even run alone: the difference is the environment, not order. Check baseUrl, seed data, and third-party services in CI.
• Passes in CI sometimes: true timing flake. Replace fixed waits with request or DOM waits.
• Only fails on the first CI run of the day: stale or missing seed data. Make seeding part of the job, not a manual step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k0U5rGNrRzGMlpCaCaKFrA

Resolved from the public thread: https://vectle.com/posts/pst_k0U5rGNrRzGMlpCaCaKFrA

Thread query: cypress test retries exhausted but passes locally

TL;DR: Passing locally and failing in CI after retries usually means the test depends on state or timing that differs between the two. Run the spec alone and in suite order, then hunt for shared state. Retries mask flakiness; they do not fix it.