{
  "doc": {
    "id": "cloud/features/smart-orchestration/run-cancellation",
    "title": "Stop failed CI runs early with auto cancellation in Cypress Cloud",
    "description": "Stop wasting CI minutes on runs that have already failed. Auto Cancellation cancels a Cypress run once failures cross a threshold you control, saving time and money.",
    "section": "cloud",
    "source_path": "/llm/markdown/cloud/features/smart-orchestration/run-cancellation.md",
    "version": "fbc9225067c51c52ee13224e3b702cf8a025ec12",
    "updated_at": "2026-08-14T12:36:26.878Z",
    "headings": [
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#auto-cancellation",
        "text": "Auto Cancellation",
        "level": 1
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#why-auto-cancellation",
        "text": "Why Auto Cancellation",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#how-it-works",
        "text": "How it works",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#activate-auto-cancellation-in-cypress-cloud",
        "text": "Activate Auto Cancellation in Cypress Cloud",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#tuning-the-threshold-for-your-team",
        "text": "Tuning the threshold for your team",
        "level": 3
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#override-the-threshold-from-the-cli",
        "text": "Override the threshold from the CLI",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#find-the-tests-that-triggered-the-cancellation",
        "text": "Find the tests that triggered the cancellation",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#what-a-canceled-run-looks-like",
        "text": "What a canceled run looks like",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#in-your-ci-output",
        "text": "In your CI output",
        "level": 3
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#impact-on-accessibility-and-ui-coverage-scoring",
        "text": "Impact on Accessibility and UI Coverage scoring",
        "level": 3
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#auto-cancellation-vs-manual-cancellation",
        "text": "Auto Cancellation vs manual cancellation",
        "level": 3
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#canceled-runs-in-analytics-and-the-data-extract-api",
        "text": "Canceled runs in analytics and the Data Extract API",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#canceled-runs-in-source-control-and-messaging-integrations",
        "text": "Canceled runs in source control and messaging integrations",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#check-for-auto-cancellation-with-cloud-mcp",
        "text": "Check for auto cancellation with Cloud MCP",
        "level": 2
      },
      {
        "id": "cloud/features/smart-orchestration/run-cancellation#see-also",
        "text": "See also",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#why-auto-cancellation",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Why Auto Cancellation",
      "heading_level": 2,
      "content_markdown": "## Why Auto Cancellation\n\nOnce a test run has failed in CI, every additional minute spent running the rest of the suite is a minute you pay for but can't use. The fix still has to be written, pushed, and validated by a _brand new_ run, so the original run keeps burning compute, holding CI machines, and recording billable tests long after you already know the outcome.\n\n**Auto Cancellation stops that waste.** When the number of failed tests crosses a threshold you set, Cypress Cloud cancels the entire run automatically. You get the signal you need, you stop paying for tests you'll never look at, and your CI pipeline is freed up to validate the fix.\n\nThe value compounds with the size of your suite and the size of your team:\n\n**Benefits:** Canceling a run once test failures reach your threshold will:\n\n1.  **Save time.** Identify failures early and resolve issues faster.\n2.  **Reduce CI costs.** Cut down on unnecessary test execution, leading to significant savings for large test suites.\n3.  **Free up CI resources.** Stop spending machines on a failed run and keep CI pipelines available for validating fixes.\n4.  **Optimize future runs.** With **[Spec Prioritization](/llm/markdown/cloud/features/smart-orchestration/spec-prioritization.md)** and **Auto Cancellation**, failed tests run first in the next attempt, stopping early if issues persist to maximize efficiency.\n",
      "section": "cloud",
      "anchors": [
        "why-auto-cancellation"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 288
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#how-it-works",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "How it works",
      "heading_level": 2,
      "content_markdown": "## How it works\n\nWhen Auto Cancellation is enabled, Cypress Cloud watches the number of failed tests across all of your parallelized machines. As soon as that count reaches your configured threshold, Cypress Cloud stops handing out new specs, marks the run as canceled, and reports how much CI time the cancellation saved.\n\n*   The default threshold is **1 failure**, so you fail fast and move on. You can raise the threshold if you'd rather let more failures surface first.\n*   Only genuinely failed tests count toward the threshold. **Flaky tests are not considered at all.** A test that fails an attempt but then passes on retry is recorded as flaky, not failed, so it never contributes to auto cancellation.\n*   Any specs that are already in progress when the threshold is reached will **finish running** so you still get their complete results.\n*   The cancellation applies to the whole run, across every machine, not just the one that reported the failure. In a parallelized run, machines that are already mid-spec will finish those specs, but **no machine starts a new spec** once the run is canceled.\n\nThis means the slower and more expensive your suite is, the more each cancellation saves you.\n",
      "section": "cloud",
      "anchors": [
        "how-it-works"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 271
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#activate-auto-cancellation-in-cypress-cloud",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Activate Auto Cancellation in Cypress Cloud",
      "heading_level": 2,
      "content_markdown": "## Activate Auto Cancellation in Cypress Cloud\n\n**Auto Cancellation** is a _Smart Orchestration_ feature available to users with a [Business or Enterprise tier Cypress Cloud plan](https://cypress.io/pricing). Wondering if upgrading your Team tier subscription is worth it? Check out the [recommendations](/llm/markdown/cloud/features/recorded-runs.md#Recommendations) on the run overview page to see how much time and money we predict these features would save you.\n\nAuto Cancellation is managed within a project's settings.\n\n**To enable or disable this feature at the Project level (must be an admin user):**\n\n1.  Select the desired project within **Projects** view to visit Cypress Cloud.\n2.  Click **Project Settings** within the right-hand sidebar.\n3.  Scroll to the **Smart Orchestration** section within the Project Settings page.\n4.  Toggle **Auto Cancellation**.\n5.  Set the **failures before auto canceling** threshold (or just leave it at the default value of 1).\n\n### Tuning the threshold for your team\n\nThe right threshold depends on how your team works:\n\n*   **Fail fast (threshold of 1).** Best when you want the earliest possible signal and the lowest possible CI spend. The run stops on the first failure.\n    \n*   **Surface more failures (higher threshold).** If your development, testing, or QA teams work in a highly collaborative workflow where multiple people fix different failures at the same time, raising the threshold lets a single run surface more of them before it cancels, so people aren't each waiting on a fresh run to see their own failure.\n    \n*   **Disable Auto Cancellation entirely.** Some branches and workflows benefit from always running the full suite, even after failures. Consider disabling it for:\n    \n    *   **Protected branches** like `main` or release branches, where you want a complete picture of every failure before merging or shipping.\n    *   **Scheduled or nightly runs** whose purpose is full coverage and trend data rather than fast feedback.\n    *   **Flaky-test investigation or quarantine runs**, where you need every test to execute to gather reliable pass/fail history.\n    *   **Runs you rely on for complete [Accessibility](/llm/markdown/accessibility/get-started/introduction.md) or [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) reports**, since a canceled run only scores the specs that ran. See [Impact on Accessibility and UI Coverage scoring](#Impact-on-Accessibility-and-UI-Coverage-scoring).\n    *   **Compliance or audit workflows** that require evidence the entire suite ran.\n    \n    You can disable it per run with `--auto-cancel-after-failures false` without changing the project default. See [Override the threshold from the CLI](#Override-the-threshold-from-the-CLI).\n    \n\n**Maximize the savings: pair with Spec Prioritization**\n\nCombine Auto Cancellation with [Spec Prioritization](/llm/markdown/cloud/features/smart-orchestration/spec-prioritization.md) to run previously failed specs first. Failures surface earlier in the run, which means Auto Cancellation triggers earlier too, shortening runs even further and driving down CI costs.\n",
      "section": "cloud",
      "anchors": [
        "activate-auto-cancellation-in-cypress-cloud"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 559
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#tuning-the-threshold-for-your-team",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Tuning the threshold for your team",
      "heading_level": 3,
      "content_markdown": "### Tuning the threshold for your team\n\nThe right threshold depends on how your team works:\n\n*   **Fail fast (threshold of 1).** Best when you want the earliest possible signal and the lowest possible CI spend. The run stops on the first failure.\n    \n*   **Surface more failures (higher threshold).** If your development, testing, or QA teams work in a highly collaborative workflow where multiple people fix different failures at the same time, raising the threshold lets a single run surface more of them before it cancels, so people aren't each waiting on a fresh run to see their own failure.\n    \n*   **Disable Auto Cancellation entirely.** Some branches and workflows benefit from always running the full suite, even after failures. Consider disabling it for:\n    \n    *   **Protected branches** like `main` or release branches, where you want a complete picture of every failure before merging or shipping.\n    *   **Scheduled or nightly runs** whose purpose is full coverage and trend data rather than fast feedback.\n    *   **Flaky-test investigation or quarantine runs**, where you need every test to execute to gather reliable pass/fail history.\n    *   **Runs you rely on for complete [Accessibility](/llm/markdown/accessibility/get-started/introduction.md) or [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) reports**, since a canceled run only scores the specs that ran. See [Impact on Accessibility and UI Coverage scoring](#Impact-on-Accessibility-and-UI-Coverage-scoring).\n    *   **Compliance or audit workflows** that require evidence the entire suite ran.\n    \n    You can disable it per run with `--auto-cancel-after-failures false` without changing the project default. See [Override the threshold from the CLI](#Override-the-threshold-from-the-CLI).\n    \n\n**Maximize the savings: pair with Spec Prioritization**\n\nCombine Auto Cancellation with [Spec Prioritization](/llm/markdown/cloud/features/smart-orchestration/spec-prioritization.md) to run previously failed specs first. Failures surface earlier in the run, which means Auto Cancellation triggers earlier too, shortening runs even further and driving down CI costs.\n",
      "section": "cloud",
      "anchors": [
        "tuning-the-threshold-for-your-team"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 377
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#override-the-threshold-from-the-cli",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Override the threshold from the CLI",
      "heading_level": 2,
      "content_markdown": "## Override the threshold from the CLI\n\nThe project setting is a sensible default, but you can override it on a per-run basis with the `--auto-cancel-after-failures` flag. This gives you granular control where it matters most:\n\n*   Set a **lower** value on dev environments to fail the suite early and get faster feedback.\n*   **Disable** Auto Cancellation on important branches (like `main` or release branches) that need the full suite to run every time.\n*   **Override** the project value for a one-off run without changing project settings.\n\nSpecifying the flag overrides the project setting in Cypress Cloud. Omitting it falls back to the project default.\n\nTo set a numeric threshold, pass the flag to `cypress run`. For example, to cancel the run after 5 test failures:\n\n*   npm\n*   Yarn\n*   pnpm\n*   Bun\n\n```\nnpx cypress run --record --key <<your_record_key>> --auto-cancel-after-failures 5\n```\n\n```\nyarn cypress run --record --key <<your_record_key>> --auto-cancel-after-failures 5\n```\n\n```\npnpm cypress run --record --key <<your_record_key>> --auto-cancel-after-failures 5\n```\n\n```\nbunx cypress run --record --key <<your_record_key>> --auto-cancel-after-failures 5\n```\n\nTo disable Auto Cancellation entirely for a run, pass `false`:\n\n*   npm\n*   Yarn\n*   pnpm\n*   Bun\n\n```\nnpx cypress run --record --key <<your_record_key>> --auto-cancel-after-failures false\n```\n\n```\nyarn cypress run --record --key <<your_record_key>> --auto-cancel-after-failures false\n```\n\n```\npnpm cypress run --record --key <<your_record_key>> --auto-cancel-after-failures false\n```\n\n```\nbunx cypress run --record --key <<your_record_key>> --auto-cancel-after-failures false\n```\n\nFor more info on passing CLI flags, see our guide on the [Cypress Command Line](/llm/markdown/app/references/command-line.md).\n",
      "section": "cloud",
      "anchors": [
        "override-the-threshold-from-the-cli"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 329
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#find-the-tests-that-triggered-the-cancellation",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Find the tests that triggered the cancellation",
      "heading_level": 2,
      "content_markdown": "## Find the tests that triggered the cancellation\n\nAfter a run is auto-canceled, the failures you care about are the ones that counted toward the threshold. You can find them in several ways:\n\n1.  **Click the failed-test indicator in the run header.** The [run header](/llm/markdown/cloud/features/recorded-runs.md#Run-header) shows counts of flaky, skipped, pending, passed, and failed tests. Clicking the failed count opens the **Test Results** tab pre-filtered to just the failures.\n    \n2.  **Or use the [Tests for Review](/llm/markdown/cloud/features/recorded-runs.md#Tests-for-Review) panel** on the Overview tab, which orders results by failures first so you land directly on the handful of tests that triggered the cancellation.\n    \n3.  **Filter the [Test Results tab](/llm/markdown/cloud/features/recorded-runs.md#Test-Results-tab)** by status to list exactly the failing tests if you arrived another way.\n    \n4.  **Without leaving your editor, you can ask your AI assistant via [Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) to surface them for you.** Example prompt for Cloud MCP:\n    \n    > \"Check Cypress Cloud for \\[Run URL\\]. If it was automatically canceled, list the failing tests that triggered the cancellation.\"\n    \n\nTo understand _why_ a test failed, open its [test detail sidebar](/llm/markdown/cloud/features/recorded-runs.md#Test-detail-sidebar) for the error, AI Error Summary, and previous-runs history, then use [Test Replay](/llm/markdown/cloud/features/test-replay.md) to time-travel to the moment of failure and inspect the DOM, network, and console as they happened in CI.\n\nBecause in-progress specs finish but no new specs start, a canceled run only contains results for the specs that had already started. The failures you see are the ones that triggered the cancellation plus any specs that were already running, not necessarily every failure the full suite would have produced. The [Errors tab](/llm/markdown/cloud/features/recorded-runs.md#Errors-tab) is a quick way to confirm you've reviewed every error that was actually recorded.\n",
      "section": "cloud",
      "anchors": [
        "find-the-tests-that-triggered-the-cancellation"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 364
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#what-a-canceled-run-looks-like",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "What a canceled run looks like",
      "heading_level": 2,
      "content_markdown": "## What a canceled run looks like\n\nWhen a run is auto-canceled, Cypress Cloud makes it clear what happened and how much it saved you. A banner summarizing the cancellation appears on the run's **Overview**, **Test Results**, and **Specs** tabs:\n\nThe banner reports:\n\n*   **What canceled the run:** _\"Automatically canceled by Smart Orchestration.\"_\n*   **How many failures triggered it:** for example, _\"After 7 test failure(s).\"_\n*   **How many specs were skipped:** for example, _\"856 of 1319 specs skipped.\"_\n*   **How much CI time was saved:** for example, _\"01:02:08 saved in CI.\"_\n*   A **Project Settings** link for adjusting your Auto Cancellation configuration.\n\nElsewhere in the run:\n\n*   The run's **Properties** tab includes a **Smart Orchestration** table showing an Auto Cancellation status of **Disabled**, **Not applied**, or **Applied**, along with detail such as _\"Configured by project to cancel after 7 test failures.\"_\n    \n*   Intelligence reports such as Accessibility and UI Coverage flag a **Partial report** badge next to the report title. Hovering it explains what happened, for example: _\"The run was canceled due to auto-cancellation and 616 specs did not run.\"_\n    \n\n### In your CI output\n\nIn the terminal output of your CI provider, each spec that was skipped because of the cancellation is reported in place of its results:\n\n```\nRunning:  commands/storage.cy.ts                                    (58 of 220)Estimated: 7 secondsThis spec and its tests were skipped because the run has been canceled.\n```\n\nThe **Run Finished** summary table at the end of the output lists those specs as **SKIPPED**, with dashes in place of their test counts, alongside the specs that actually ran:\n\n### Impact on Accessibility and UI Coverage scoring\n\nBecause a canceled run skips the specs that never started, your [Accessibility](/llm/markdown/accessibility/get-started/introduction.md) and [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) reports are calculated from only the part of your application that was exercised before cancellation. Keep this in mind when reading the scores:\n\n*   **Accessibility score** is the average score across all snapshots captured during the run. A canceled run captures fewer snapshots, so the score reflects only the pages and states that ran, and is not directly comparable to a score from a complete run of the same suite.\n*   **UI Coverage** measures the interactive elements your tests exercised. Skipped specs mean those elements are never visited, so coverage will appear lower than a full run and will not represent your suite's true coverage.\n\nFor this reason, treat scores from a canceled run as a partial sample rather than the run-over-run trend you compare against. If you rely on these scores to [block pull requests](/llm/markdown/accessibility/guides/block-pull-requests.md) or track regressions, consider [disabling Auto Cancellation](#Tuning-the-threshold-for-your-team) on the branches or runs where you need complete coverage.\n\n### Auto Cancellation vs manual cancellation\n\nA run can be canceled in two ways, and Cypress Cloud distinguishes between them:\n\n*   **Auto Cancellation**: the run reached the configured failure threshold and Cypress Cloud canceled it. The UI describes the run as _\"canceled due to auto-cancellation.\"_\n*   **Manual cancellation**: a user canceled the run from Cypress Cloud. The UI describes the run as _\"manually canceled\"_ and records who canceled it.\n\nFor more common questions, see the Auto Cancellation section of the [Cypress Cloud FAQ](/llm/markdown/cloud/faq.md#Auto-Cancellation).\n",
      "section": "cloud",
      "anchors": [
        "what-a-canceled-run-looks-like"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 692
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#in-your-ci-output",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "In your CI output",
      "heading_level": 3,
      "content_markdown": "### In your CI output\n\nIn the terminal output of your CI provider, each spec that was skipped because of the cancellation is reported in place of its results:\n\n```\nRunning:  commands/storage.cy.ts                                    (58 of 220)Estimated: 7 secondsThis spec and its tests were skipped because the run has been canceled.\n```\n\nThe **Run Finished** summary table at the end of the output lists those specs as **SKIPPED**, with dashes in place of their test counts, alongside the specs that actually ran:\n",
      "section": "cloud",
      "anchors": [
        "in-your-ci-output"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 107
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#impact-on-accessibility-and-ui-coverage-scoring",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Impact on Accessibility and UI Coverage scoring",
      "heading_level": 3,
      "content_markdown": "### Impact on Accessibility and UI Coverage scoring\n\nBecause a canceled run skips the specs that never started, your [Accessibility](/llm/markdown/accessibility/get-started/introduction.md) and [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md) reports are calculated from only the part of your application that was exercised before cancellation. Keep this in mind when reading the scores:\n\n*   **Accessibility score** is the average score across all snapshots captured during the run. A canceled run captures fewer snapshots, so the score reflects only the pages and states that ran, and is not directly comparable to a score from a complete run of the same suite.\n*   **UI Coverage** measures the interactive elements your tests exercised. Skipped specs mean those elements are never visited, so coverage will appear lower than a full run and will not represent your suite's true coverage.\n\nFor this reason, treat scores from a canceled run as a partial sample rather than the run-over-run trend you compare against. If you rely on these scores to [block pull requests](/llm/markdown/accessibility/guides/block-pull-requests.md) or track regressions, consider [disabling Auto Cancellation](#Tuning-the-threshold-for-your-team) on the branches or runs where you need complete coverage.\n",
      "section": "cloud",
      "anchors": [
        "impact-on-accessibility-and-ui-coverage-scoring"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 235
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#auto-cancellation-vs-manual-cancellation",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Auto Cancellation vs manual cancellation",
      "heading_level": 3,
      "content_markdown": "### Auto Cancellation vs manual cancellation\n\nA run can be canceled in two ways, and Cypress Cloud distinguishes between them:\n\n*   **Auto Cancellation**: the run reached the configured failure threshold and Cypress Cloud canceled it. The UI describes the run as _\"canceled due to auto-cancellation.\"_\n*   **Manual cancellation**: a user canceled the run from Cypress Cloud. The UI describes the run as _\"manually canceled\"_ and records who canceled it.\n\nFor more common questions, see the Auto Cancellation section of the [Cypress Cloud FAQ](/llm/markdown/cloud/faq.md#Auto-Cancellation).\n",
      "section": "cloud",
      "anchors": [
        "auto-cancellation-vs-manual-cancellation"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 111
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#canceled-runs-in-analytics-and-the-data-extract-api",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Canceled runs in analytics and the Data Extract API",
      "heading_level": 2,
      "content_markdown": "## Canceled runs in analytics and the Data Extract API\n\nA canceled run is recorded with a terminal status of `cancelled`, and that status flows through to [Analytics](/llm/markdown/cloud/features/analytics/overview.md) and the [Data Extract API](/llm/markdown/cloud/integrations/data-extract-api.md). Because a canceled run only ever recorded part of its tests, it carries **partial data**, which is treated differently depending on the report:\n\n| Surface | How a canceled run is handled |\n| --- | --- |\n| [Run status](/llm/markdown/cloud/features/analytics/project-analytics.md#Run-status) analytics | Counted in its own canceled bucket. Pass and fail rates are calculated against all runs, so canceled runs sit in the denominator and dilute those rates. |\n| [Run duration](/llm/markdown/cloud/features/analytics/project-analytics.md#Run-duration) and [Test suite size](/llm/markdown/cloud/features/analytics/project-analytics.md#Test-suite-size) analytics | Excluded. These reports only consider completed (passed/failed) runs so partial runs don't skew the averages. |\n| [Top failures](/llm/markdown/cloud/features/analytics/project-analytics.md#Top-failures), [Slowest tests](/llm/markdown/cloud/features/analytics/project-analytics.md#Slowest-tests), most common errors, and flakiness analytics | Included implicitly. They aggregate individual test results, so any results recorded before cancellation count, and canceled runs contribute to failure-rate denominators. |\n| [Data Extract API](/llm/markdown/cloud/integrations/data-extract-api.md#Run-status) | Included. Run-level reports return a `cancelled` status, and test-level data reflects whatever completed before cancellation. |\n\nThe key thing to keep in mind: a canceled run's **partial results still count** in the test-level reports above, so a run that auto-canceled after a few failures can nudge aggregate failure rates and trends. If you track these metrics closely, consider [disabling Auto Cancellation](#Tuning-the-threshold-for-your-team) on the runs you rely on for complete analytics.\n\nNote that analytics and the Data Extract API only know that a run was `cancelled`; they do not distinguish an **Auto Cancellation** from a manual one. That distinction is available in the Cloud dashboard (see [Auto Cancellation vs manual cancellation](#Auto-Cancellation-vs-manual-cancellation)) and through [Cloud MCP](#Check-for-auto-cancellation-with-Cloud-MCP).\n",
      "section": "cloud",
      "anchors": [
        "canceled-runs-in-analytics-and-the-data-extract-api"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 375
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#canceled-runs-in-source-control-and-messaging-integrations",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Canceled runs in source control and messaging integrations",
      "heading_level": 2,
      "content_markdown": "## Canceled runs in source control and messaging integrations\n\nCypress Cloud's integrations report a canceled run wherever they report run results, but, like analytics, they only convey that the run was _canceled_. None of them distinguish an Auto Cancellation from a manual one.\n\n| Integration | How a canceled run is surfaced |\n| --- | --- |\n| [GitHub](/llm/markdown/cloud/integrations/github.md) status checks | Reported as a completed check with a `failure` state and a description such as `This {spec/group/run} was cancelled` |\n| [GitLab](/llm/markdown/cloud/integrations/gitlab.md) status checks | Reported with GitLab's native `canceled` state and the same description. |\n| [Bitbucket](/llm/markdown/cloud/integrations/bitbucket.md) status checks | Reported with Bitbucket's native `STOPPED` state and the same description. |\n| Pull request and merge request comments (GitHub, GitLab, Bitbucket) | The run's properties show a canceled icon labeled _\"Cancelled,\"_ and any canceled specs are grouped under **Failed tests** with the failed icon. |\n| [Slack](/llm/markdown/cloud/integrations/slack.md#Notification-preferences) and [Microsoft Teams](/llm/markdown/cloud/integrations/microsoft-teams.md#Notification-preferences) | A canceled run only notifies a channel when its **Canceled runs** notification preference is enabled. It then appears as _\"Canceled run\"_ with a gray skipped icon. |\n\nBecause these integrations don't differentiate auto from manual cancellation, use the [Cloud dashboard](#Auto-Cancellation-vs-manual-cancellation) or [Cloud MCP](#Check-for-auto-cancellation-with-Cloud-MCP) when you need to confirm that a run was specifically auto-canceled by Smart Orchestration.\n",
      "section": "cloud",
      "anchors": [
        "canceled-runs-in-source-control-and-messaging-integrations"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 281
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#check-for-auto-cancellation-with-cloud-mcp",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "Check for auto cancellation with Cloud MCP",
      "heading_level": 2,
      "content_markdown": "## Check for auto cancellation with Cloud MCP\n\n[Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) lets your AI coding assistant query Cypress Cloud directly, so you can ask an agent whether a run was auto-canceled without opening the Cloud UI. The `cypress_get_runs` tool returns run summaries that include the run's status and test-status counts.\n\nA canceled run reports a status of `cancelled`. From there, Cloud MCP distinguishes an Auto Cancellation from any other cancellation:\n\n*   When the run was canceled because it reached the failure threshold, the agent reports something like: _\"Run automatically canceled by Smart Orchestration after 7 test failure(s). 616 of 1319 specs skipped.\"_ The skipped count is the number of specs that never ran (the expected specs minus the ones that completed).\n*   When the run was canceled some other way (for example, from CI or by a user), the agent reports a plain _\"Run canceled. N of M specs skipped\"_ without the Smart Orchestration attribution.\n\nThis makes it easy to confirm, in your editor, that a red build was an intentional early cancellation rather than a different kind of failure.\n\n**Example prompts:**\n\n> \"Using Cypress Cloud, was the latest run on this branch auto-canceled by Smart Orchestration? If so, how many failures triggered it and how many specs were skipped?\"\n\n> \"Check Cypress Cloud for \\[Run URL\\]. If it was automatically canceled, list the failing tests that triggered the cancellation.\"\n\nFor setup and the full tool list, see the [Cloud MCP guide](/llm/markdown/cloud/integrations/cloud-mcp.md).\n",
      "section": "cloud",
      "anchors": [
        "check-for-auto-cancellation-with-cloud-mcp"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 321
    },
    {
      "id": "cloud/features/smart-orchestration/run-cancellation#see-also",
      "doc_id": "cloud/features/smart-orchestration/run-cancellation",
      "heading": "See also",
      "heading_level": 2,
      "content_markdown": "## See also\n\n*   [Smart Orchestration Overview](/llm/markdown/cloud/features/smart-orchestration/overview.md)\n*   [Spec Prioritization](/llm/markdown/cloud/features/smart-orchestration/spec-prioritization.md), which surfaces previously failed specs first so Auto Cancellation can trigger even earlier\n*   [Parallelization](/llm/markdown/cloud/features/smart-orchestration/parallelization.md) and [Load Balancing](/llm/markdown/cloud/features/smart-orchestration/load-balancing.md)\n*   The [`--auto-cancel-after-failures`](/llm/markdown/app/references/command-line.md#auto-cancel-after-runs) flag in the Cypress Command Line reference\n*   [Recorded Runs](/llm/markdown/cloud/features/recorded-runs.md) for navigating run results and finding failed tests\n*   [Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) for querying run status from your AI coding assistant\n*   [Auto Cancellation FAQ](/llm/markdown/cloud/faq.md#Auto-Cancellation)\n",
      "section": "cloud",
      "anchors": [
        "see-also"
      ],
      "path": "/llm/json/chunked/cloud/features/smart-orchestration/run-cancellation.json",
      "token_estimate": 87
    }
  ]
}