Which Cypress runs do you let Auto Cancellation stop early, and which must run whole?
answer
- Ask what the run is for
- Fast verdict versus complete evidence
- One failure is a policy, not a default
- Protected branches want everything
- Override per run, not per build
basics
~20 sCancel early where the run exists to give one author a fast verdict: pull-request and branch runs. Let it run whole where the deliverable is a complete picture: release branches, nightly coverage runs, and flake investigations.
solid answer
~50 sDecide per run type, by asking what the run is *for*. A pull-request run answers one question — does this change work — so once it has failed, every further spec produces information nobody will act on before the fix is pushed; a threshold of one is right. A release or nightly run exists to produce the complete failure picture and coverage data, so cancelling it destroys the artefact it was scheduled to create; disable it there. Between the two sits a shared branch where several people fix different failures at once, and a slightly higher threshold buys them parallel debugging. Express the common case as the Cypress Cloud project default and the exceptions as `--auto-cancel-after-failures` on the pipeline command itself, so the decision is visible beside the run it governs. And remember it only makes *failing* runs cheaper: a green run still executes everything.
go deeper
Know that Cypress Auto Cancellation can be switched off for a single run with a CLI flag, and that some runs are meant to execute in full regardless of failures.
Explain the trade the threshold makes — earlier feedback against a less complete failure picture — and where the project setting ends and the per-run override begins.
Show you have operated it: which branches you exempted, what a canceled run does to coverage-style reports and failure-rate aggregates, and how the team learned to read one.
Own the policy across pipelines: the default threshold, the exemptions and their reasons, and how the decision stays visible in the pipeline command rather than buried in a settings page.
## Start from the question the run answers Auto Cancellation trades completeness for speed, so the decision is not "is early cancellation good?" but "what is this particular run for?" Two runs of the same suite can want opposite answers: - A **pull-request run** exists to tell one author whether their change works. Once it has failed, every further spec is time spent producing information nobody will act on before the fix is pushed. Cancel early. - A **nightly or release run** exists to produce a complete picture — every failure, full coverage data, evidence the suite ran. Cancelling it destroys the artefact it was scheduled to create. Leave it alone. Everything else is a variation on that question. ## The threshold is a policy, not a default Cypress Cloud's default threshold is one failure. Where you move it says something about how your team works: 1. **Threshold of 1 — fail fast.** The earliest possible signal and the least machine time spent on a run whose verdict is already known. The right default for branch and pull-request runs. 2. **A higher threshold — surface more before stopping.** Worth it when several people are fixing different failures at once, because each of them would otherwise have to wait for their own fresh run to see their own failure. You are buying parallel debugging with machine time. 3. **Off — run everything.** For runs whose value is the complete result set rather than a fast verdict. ## Runs that should not be cut short - **Protected branches** such as `main` and release branches, where you want every failure before deciding to ship. - **Scheduled full-suite runs**, whose purpose is coverage and trend data rather than fast feedback. - **Flake investigations and quarantine verification runs**, which need every test to execute to produce usable pass/fail history — cancelling one biases exactly the data you are gathering. - **Runs you rely on for reports that score what the suite exercised**, since a canceled run scores only the specs that ran and the number is not comparable with a complete run's. - **Compliance or audit workflows** that need evidence the whole suite ran. ## Know what cancellation does to your numbers A canceled run carries partial data, and different surfaces treat that differently: duration-style reports exclude it so averages are not skewed, while test-level reports include whatever completed, so partial results still move failure-rate aggregates. Status checks and chat notifications report only that a run was *canceled*, with no distinction between Auto Cancellation and someone pressing cancel — so if your team reads red builds off notifications, expect "was this cancelled early or did it really break?" to become a recurring question, and point people at the run's banner and Properties tab for the answer. ## Cancellation is not a substitute for a shorter suite A threshold of one makes a *failing* run cheap. It does nothing at all for the green run everyone actually waits on, which still executes every spec at full length. So if the complaint you are answering is "the suite takes too long", cancellation is the wrong lever — it only pays out on runs that were going to fail anyway. Reach for it to stop paying for a verdict you already have, and keep spec-level balance and machine count as the levers for the passing case. ## Express the decision where it is readable | run type | setting | because | |---|---|---| | pull request, branch | threshold 1 | fastest verdict on one change | | shared integration branch | a small number | several failures worth seeing at once | | release branch, nightly | `--auto-cancel-after-failures false` | the complete failure picture is the deliverable | | flake investigation | off | partial data is worse than none | Set the common case as the project default and express the exceptions as `--auto-cancel-after-failures` on the specific pipeline invocation, rather than flipping the project setting per build — the flag lives beside the command it affects and is reviewable in the same diff as the pipeline change. And if you keep cancellation on, pair it with Spec Prioritization: with the previously failed specs at the front of the queue, a still-broken change trips the threshold in the first minute of the run instead of halfway through, which is the difference between cancelling a run that had barely started and cancelling one that has already consumed most of its machines' time on specs you will never read.
- Your team keeps asking whether a red Cypress build really broke or was cancelled early. How do you fix that?Status checks and chat notifications report only that a run was canceled, with no distinction between an automatic cancellation and someone pressing cancel in the Cloud. The distinction lives on the run itself — the banner naming the failure count and skipped specs, and the Properties tab showing Auto Cancellation as Applied. Teach people to open the run, and consider disabling cancellation on the branches whose notifications people act on without looking.
- Why does raising the threshold from 1 to 5 not simply make runs five times more expensive?It stops the run after five failed tests rather than one, so the extra cost is bounded by whatever runs between those failures — often a few specs, since the failures tend to cluster. What you buy is several people seeing their own failure in one run instead of each waiting for a fresh one. On a suite where failures are usually a single root cause, though, the extra specs mostly re-report the same break.
saying these in an interview costs you the question
- Applies one cancellation policy to every run type
- Cancels nightly or release runs that exist for coverage
- Cancels flake investigation runs and trusts the data
- Treats the project default as unchangeable per run
- Judges the policy purely on machine time saved