How do you decide whether a Cypress suite should depend on Cypress Cloud to parallelise?

## Name what you are buying, and what you are renting The runner is open source and it is complete: `cypress run` executes a storefront monorepo's suite, retries, captures artefacts and exits with a status. What Cypress Cloud sells is **coordination and history** — assigning specs to machines by measured duration, one combined view of a run spread over several jobs, re-running only what failed, and keeping results over time. The decision is not "should we use Cypress" but "should the fan-out step of our build depend on a service we do not operate". State the trade in the interview before you state a preference. Three things are being traded: - **Wall-clock time** you get back on every pipeline run. - **Money**, metered by recorded test results — each **passed or failed** test recorded under `--record`. Pending and skipped tests are not counted, and archiving a run afterwards does not un-count it. - **Availability of your build**, which now includes a network hop and a valid record key. ## The failure modes that decide it A dependency is worth its price until it fails in a way you did not plan for. There are three worth naming, and only the last one usually surprises people: 1. **The key or the network.** Every parallelising job needs the record key and reachable endpoints. Rotate the key badly and every CI job fails at once; block egress on a new runner image and the same. This is ordinary and manageable — but note it fails the *run*, not merely the reporting, because `--parallel` cannot proceed without the coordinator. 2. **Growth you did not model.** Metering follows test count, so the bill tracks suite growth, and it also tracks *how often you record*. Recording every local and every dev-branch run multiplies usage without multiplying insight. 3. **Exhausting the account's recorded-result allowance mid-cycle.** This is the one to know: recorded runs keep running, but **parallelisation is disabled** and new results stop appearing until the cycle resets. Your pipeline does not go red — it goes *slow*, silently, and the dashboards you were relying on stop filling in. A team that has never thought about this discovers it during a release. And the structural one behind all three: there is **no self-hosted Cypress Cloud**. The exit is not a migration to an equivalent you run yourself; it is a fall back to splitting specs by hand. ## How to decide 1. **Measure the serial number first.** Time `cypress run` over the whole suite and compare it with the feedback budget you actually need. A suite that finishes inside the budget on one machine has no orchestration problem to solve, and buying one is premature. 2. **Try the free shape before the paid one.** A derived, filesystem-based `--spec` split across CI jobs recovers most of the wall-clock win. If that gets you inside budget, the remaining value of the service is balancing quality, history and re-run selection — real, but a smaller purchase to justify. 3. **Price the metering against the suite you are heading for, not the one you have.** Ask what the test count looks like in a year, and whether you intend to record every branch or only the ones you review. 4. **Decide what a service outage may do to a deploy.** If the answer is "must not block", your pipeline needs a non-recording path it can take, and that path has to be exercised, not theoretical. ## Keeping the exit cheap Lock-in on this tree is mild if you engineer for it, and severe if you do not. The discipline is to keep the dependency at the **invocation** layer and out of the test code: - Specs, `cypress.config.js`, custom commands and fixtures should contain nothing that assumes recording. If a plain `cypress run` is not a valid command in your repository, that is the lock-in, and it is self-inflicted. - Keep the shard-derivation script in the repository whether or not you use it, so falling back is a flag change rather than a project. - Put the record key in the environment and treat it as an operational secret with a rehearsed rotation, not a value pasted into a workflow file. - Watch usage as a trend with an alarm before the allowance runs out, so the "silently slower" failure is something you were warned about. | Question to answer | Points to recording | Points to hand-splitting | |---|---|---| | Serial wall-clock vs budget | Far over, and growing | Near or inside budget | | Spec durations | Wildly uneven, hard to partition | Broadly comparable | | Tolerance for a build-time dependency | Acceptable, with a fallback | Build must not need the network | | Who maintains the split | Nobody has the time | A script and an owner exist | | Value of run history and re-run selection | High — many teams read it | Low — CI logs suffice | The answer an interviewer wants is not a verdict. It is that you can price both sides, name the allowance-exhaustion behaviour, and describe the fallback you would keep working.