Cypress Cloud: Recording, Test Replay, Orchestration & Analytics

Cypress Cloud never runs your tests and never sees your application’s source code. Your tests still execute on your own machines (a laptop or CI agents) with the Cypress App; when you pass --record, the App also uploads the results, and Cloud stores them. In exchange you get:

Source: Cypress Cloud introduction

The data stored for a recorded run is the terminal output, test results and definitions, the Cypress configuration (without Cypress environment variables), screenshots, videos, and the CI and git environment variables. With Test Replay enabled it also includes the rendered DOM and CSS, the Command Log events, network traffic and console logs of the application under test. Test content can be shared with an AI model only when Cloud AI features are enabled, and the documentation states that customer data is not used to train models.

Source: Data storage and controls

The examples use a small project, cy-cloud, with three spec files. The split into several files matters: Cypress parallelizes whole spec files, so a project with a single spec cannot benefit from more than one machine.

Source: Cypress Cloud: Project ID

Source: Writing and organizing tests

Source: cy.session

cy.signIn() is the cached-session command from Sessions, Authentication & Cross-Origin; it reads the password with cy.env() from the variable CYPRESS_READER_PASSWORD, so no password appears in a file. The third spec fails on purpose on its first attempt, to show what Cloud calls a flaky test (see Flaky test management):

Source: Test retries

Running the project locally, without recording, against Bookshelf on port 3928 (Electron, headless, which is the default for cypress run):

Source: Command line: cypress run

The terminal reports four passing tests and exit code 0, and the "Attempt 1 of 3" line is the only trace of the failed first attempt of the flaky test. Cypress also saved a failure screenshot for that attempt. This is exactly the situation where a terminal alone hides information that Cloud keeps. Electron is deprecated as a test browser since Cypress 16.0.0 and the run prints "Electron 146 (headless) (deprecated)"; it is used here because it ships with Cypress. Cloud features that need a Chromium-based browser (Test Replay) work with Chrome and Edge as well.

Every recorded run appears under Latest Runs, filterable and paginated, with the branch, author, commit, duration and counts of flaky, skipped, pending, passed and failed tests. The details page of one run has four tabs:

Opening a test shows a detail sidebar: status and spec, a Cloud AI "Test Intent Summary" and "At a glance" Error Summary (when Cloud AI is enabled), each attempt with its error, stack trace and code frame, the history of previous runs of that test, the screenshots, videos and CI log, and the commits that touched the test with their diffs. The diff is of the transpiled code, since source maps are not collected.

A test is marked Modified when its body or the hooks around it (before, beforeEach, afterEach, after) differ from an earlier recorded version, and New when none exists. Tests are matched by spec file path and test title, so renaming either makes Cloud see a new test. The comparison also considers the base branch, so a test may show as modified in a branch where you did not touch it.

A run in progress can be cancelled from its page (by project members) or through the Run Cancellation API (which needs the record key); results already recorded still count toward your usage. Cancelled or errored runs can be archived, which hides them from lists and analytics but not from usage counts.

The Cypress App connects to the same data. After you log in, the Runs page shows recorded runs for the current branch, the Debug page brings failed CI runs into the App so you can rerun and debug them locally, and, since Cypress 12.17.0 on macOS and Linux, desktop notifications tell you when a run on your current commit starts, fails or completes.

Source: Recorded runs

Test Replay replaces "reproduce it locally" for failures that happened in CI. During a recorded cypress run, Cypress captures the commands, network requests, console logs, JavaScript errors, DOM mutations, CSS, SVG, iframes, shadow DOM and canvas elements. Cloud rebuilds the page from that data, so you open a test and get the Command Log with time travel, the developer tools (network, console, element inspection) and playback controls, with a timeline that lets you scrub through each attempt. It is the same debugging model as the App’s Command Log, but for a run that is long over.

Test Replay data is visible to everyone with access to the project. By default Cypress redacts sensitive values locally, before upload: authentication headers (authorization, cookie, set-cookie, x-api-key), credential fields in bodies (password, client_secret, access, refresh and ID tokens), tokens in URL parameters, and JWT and SAML patterns, shown as (redacted). Values typed into password, hidden and payment fields are masked with asterisks. Response bodies larger than 512 KB are dropped. Owners and admins can turn redaction or masking off per project, which you should do only with test data that contains nothing sensitive.

Troubleshooting follows a short list: the button is disabled when the run used a version older than 13, a non-Chromium browser, a project with Test Replay disabled, or when the upload failed (network, firewall, or a spec that outlasted the project’s run timeout; see the standard output of the spec).

The same captured data is reachable from a terminal, which is useful for scripts and AI agents:

Source: Test Replay

These commands need an authenticated Cloud account and were not run here. Test Replay itself was not run either, since no recorded run exists.

Smart Orchestration is the family of features that run your recorded tests faster and cheaper in CI.

Source: Smart Orchestration overview

A test is flaky when it fails an attempt and then passes on retry without a code change. Cypress Cloud detects flakiness from test retries, so retries must be on for recorded runs; the project above has retries: { runMode: 2, openMode: 0 }, which retries only under cypress run. The local run shown earlier is a faithful miniature of what Cloud sees: attempt 1 fails, attempt 2 passes, the test is reported as passed, and the run is flagged as containing one flaky test. Cloud keeps the failed attempt (error, screenshot and, with Test Replay, the full replay), which the terminal does not.

Flake detection, flake analytics and alerts need a Team plan or higher. The pieces are:

The run.completed webhook carries flakyTestCount, which counts passing tests that failed at least one attempt. Experimental flake-detection features that change a flaky test’s pass or fail result are described in the experiments reference. The tool-independent discussion of why tests flake and how to remove the cause is in Flaky Tests & Reliability.

Source: Flaky Test Management

Cloud was not available, so none of the detection, scoring or alert screens was seen; the local run above only demonstrates the retry behaviour that feeds them.

Branch Review compares a changed run with a base run in one view: new failures, flaky tests, pending tests, tests that were added or modified, and, if enabled, how UI Coverage and Accessibility changed. Every test state is labelled new (introduced by the branch), existing (already on the base) or resolved (no longer present), so reviewers can separate what the pull request caused from pre-existing noise. Opening a test shows the base and feature results side by side with Test Replay, screenshots, attempts and the code diff.

You reach it from the project list, the Branches navigation, a run’s branch name, or the "View all changes introduced in this branch" link in the Cypress pull request comment. It needs the GitHub integration with pull request comments for the pull-request path, but it compares any two runs, so it also works for nightly runs or different builds. If one branch has no run for the relevant commit, Branch Review falls back to the last run on that branch or shows non-comparison data; a banner names the missing commit. It is on every plan.

Source: Branch Review

Source: Types of Analytics

Integrations are configured by organization owners and admins in Cypress Cloud, never in the test code.

Source: GitHub integration

Status checks are what turn Cypress into a merge gate: make the Cypress check required in the branch protection rules and a failing or flaky run blocks the merge. The integration depends on the CI environment providing the commit SHA, which is why the COMMIT_INFO_SHA setting above matters.

UI Coverage is a premium Cloud product that answers a question code coverage cannot: which interactive things a user can do in your application are exercised by your tests. It needs no code changes, plugin or instrumentation. Cloud analyzes the DOM snapshots that Test Replay already captured for every unique state reached in end-to-end and component tests, finds every interactive element (buttons, inputs, links and so on), and checks whether a recognized Cypress interaction command touched it. The report on the run’s UI Coverage tab shows:

Requirements are a project that records with Test Replay enabled, Cypress 13 or later, and UI Coverage enabled for the organization, which starts with a free-trial request. Configuration lives in Cloud, not in the repository: the App Quality tab of the project settings holds a JSON document validated on save, with options such as elementFilters, viewFilters, views, elements, elementGroups, significantAttributes, attributeFilters, additionalInteractionCommands, allowedInteractionCommands and profiles (different settings by run tag). A historical run can be reprocessed after a change without re-running the tests. This is the documentation’s example, which hides a chat widget and a third-party login:

Source: UI Coverage: Get started

Reports are produced after the run is recorded, so nothing in the pipeline waits for them. To turn the report into a merge gate, install the @cypress/extract-cloud-results module in CI (from the tarball at https://cdn.cypress.io/extract-cloud-results/v1/extract-cloud-results.tgz, not committed as a dependency) and call getUICoverageResults() after cypress run --record in the same CI build; it finds the run from the CI environment, polls until the report is ready and returns the scores:

Source: UI Coverage: Results API

The script’s syntax was checked, but it was not run: it needs a UI Coverage subscription and a recorded run. The guides also describe gating on new gaps against a committed baseline rather than on a fixed score, which avoids blocking every pull request in an application that already has coverage debt. UI Coverage appears in Branch Review, in Enterprise Reporting (since May 2026), through the run.uiCoverage.completed webhook and through three Cloud MCP tools added in April 2026.

Cypress Accessibility is the sibling premium product. It runs the Deque axe-core rules over the DOM snapshots of every unique state reached in your tests, server-side, with no effect on test execution and no accessibility code in the tests. It needs the same prerequisites as UI Coverage (recording with Test Replay, Cypress 13 or later, the product enabled by a trial) and produces a report on the run’s Accessibility tab: a percentage score, violations per view, and, for each violation, an inspectable DOM snapshot that highlights the element.

The score is the average over all snapshots of the ratio of passing check weights to total weight, where failed checks are weighted by axe impact: critical 10, serious 7, moderate 3, minor 1. Incomplete and ignored results do not affect it. The configuration is edited in the same App Quality tab and includes element filters, view filters, views, significantAttributes, attributeFilters, profiles and, since the week of 5 October 2026, accessibility.axeConfig to enable or disable individual rules or restrict a report to tags such as WCAG 2.1 A and AA. Reports can be downloaded as CSV or JSON (since the week of 24 August 2026), compared in Branch Review to review only newly introduced violations, delivered through the run.accessibility.completed webhook, and enforced from CI with a Results API analogous to the UI Coverage one. It also supports scheduled runs against production for monitoring. Note that automated rules find only a part of the accessibility problems; the guides themselves recommend combining them with manual review. For checks that run inside the test itself (such as axe through cypress-axe), see Accessibility Checks in E2E Tests.

Source: Cypress Accessibility

Neither product was available without a subscription, so the reports described here were not seen. The in-test cypress-axe check on the Bookshelf home page is the free alternative; it ran against the example application with no violations in the shared Cypress project, and cypress-axe 1.7.0 declares a peer range that stops at Cypress 15, so installing it next to Cypress 16 needs --legacy-peer-deps.

Prices and limits change; the table below was read from https://www.cypress.io/pricing on 25 October 2026 with annual billing selected, in USD, and should be rechecked before a decision. The Cypress App is free under the MIT licence regardless of plan. Every account can start a 30-day free trial that includes the premium features.

Source: Cypress Cloud pricing

How usage is counted decides the bill. A test result is each passed or failed it() recorded with --record; a test that retries counts once, and skipped or pending tests, local runs without --record and anything that prevents a test from running are not counted. Results are consumed in the order included, bundled, then on-demand. When the included and bundled results are used up and your subscription has no on-demand pricing, recording still runs but parallelization is disabled and new results are hidden from the dashboard until you upgrade or the billing period resets. The Billing & Usage page shows usage over time and per project (downloadable as CSV), and owners and admins can create an email notification at a threshold of their choice. Ways to lower the bill are to record only in CI, to record only the browsers you need, to enable Auto Cancellation and re-run optimization where your subscription has them, and to remove redundant tests.

Qualifying open-source projects (non-commercial, public in Cloud, source under an OSI-approved licence, at least 500 tests) can request a free Open Source plan with five users, 100k test results per month, parallelization with load balancing and the integrations. The pricing page lists status checks and pull request comments for GitHub, GitLab and Bitbucket on Starter and Team, and for GitHub and GitLab, including their self-managed Enterprise variants, on Business and Enterprise; the integration documentation describes a Bitbucket integration without plan restrictions, so confirm Bitbucket on Business with Cypress if you rely on it. Plan figures can also differ for monthly billing, which was not checked.

Source: Billing & usage in Cypress Cloud