Writing test cases and running them is only half the job. The other half is reporting: tracking which tests passed, failed, or got skipped, and seeing why. In Cypress, that reporting lives in Cypress Cloud, the platform formerly known as Cypress Dashboard.

Cypress runs your tests. Cypress Cloud is where you look when they fail. It records every run, stores the test video and screenshots, surfaces flaky tests, and turns a red CI log into something you can actually read. The official docs refer to these "recorded runs" (see the Cypress Cloud recorded runs documentation).

That is the pitch. The reality has limits, a price tag, and a growing list of teams asking whether Cypress is still the right place to be. We will record a real run, identify those limits, review the free Cypress Cloud alternative, and weigh whether to stay on Cypress at all.

What is Cypress Cloud (Cypress Dashboard)?

Cypress Cloud is a hosted service that records your Cypress test runs and makes them readable after the fact. Cypress, the test runner, runs on your machine or in CI. Cypress Cloud is the web app where the results land.

Here is the plain version of what it gives you:

1. Run history: every recorded run, who triggered it, on which branch, pass or fail.

2. Test results with media: the video of the run, screenshots at the point of failure, and the error and stack trace, all attached to the specific test.

3. Test Replay: a way to step back through the DOM and network of a failed run, instead of only watching a video of it. See the Cypress Test Replay documentation.

4. Parallelization and load balancing: Cloud splits your specs across multiple CI machines and balances them so the whole suite finishes faster (the Cypress parallelization docs).

5. Analytics: flake rate, slowest tests, run duration over time, and the most common errors across runs.

That is the core trade. Cypress the runner is free and open source. The recording, the history, and the team-visibility layer are the paid product. None of this changes how you write tests. It changes what you can see after they run.

A neutral way to think about it: Cypress Cloud is not a different test framework. It is observability bolted onto the framework you already use. The tests are yours, and Cloud remembers and explains them.

What Cypress Cloud actually includes in 2026

Most write-ups stop at "it records your runs." The product has moved on, and a few details change the buying decision. Here is the current state, with the parts vendors tend to gloss over.

Test Replay has real limits: It is free on every plan and lets you step back through a run's DOM and network. But it only records in Chromium-based browsers (no Firefox or WebKit replay), requires Cypress v13+, and does not capture video or audio elements, server-sent events, WebSockets, localStorage, sessionStorage, cookies, or cy.request traffic. See the Cypress Test Replay docs.

Smart Orchestration is 4 features, not 1, and they are tiered: Parallelization and Load Balancing are available on paid plans (load balancing is enabled by default with --record --parallel). Spec Prioritization and Auto Cancellation are Business plan and up. Reference: Cypress Smart Orchestration.

Flaky detection is scored, and it costs: Cypress bands flakiness by rate: Low (0–10%), Medium (10–50%), High (above 50%). Useful, but flaky-test management starts at the Team plan, not the free tier. See Cypress flaky test management.

The AI features are new and capped: cy.prompt() (Beta) turns plain-English steps into commands, with hourly caps (100 prompts on Free, 600 on paid). Test Intent and Error Summaries are generally available and free. Details: Cypress AI features.

None of this is a knock on Cypress Cloud. It is the honest version of what you get, and which parts sit behind which paywall. ✅

How to record your first run with Cypress Cloud

You do not need a big app to try this. The example below uses the open-source Cypress RealWorld App, a sample banking app the Cypress team maintains specifically for demos like this. The steps are the same for any project.

1. Install Cypress

Cypress installs as a dev dependency. Pick whichever package manager your project uses.

Via npm:

npm install cypress --save-dev

Via Yarn:

yarn add cypress --dev

Via pnpm:

pnpm add -D cypress

2. Connect the project to Cypress Cloud

Create a free account at cloud.cypress.io, create a project, and Cypress hands you two things: a project ID and a record key.

The project ID goes in your config file so Cypress knows which Cloud project to talk to:

module.exports = {
  projectId: "your-project-id",
  // ...rest of the Cypress project config
}

3. Record a run

The record key is the secret that authorizes the upload. Run your tests with --record and pass the key:

npx cypress run --record --key <your-record-key>

That is the whole thing. Cypress runs the specs headless, then uploads the results, video, and screenshots to Cloud. When it starts, it prints the Cloud URL for that exact run (the full flag reference lives in the Cypress run command docs):

That Run URL is your run, live in Cloud, filling in as specs finish. When the run completes, Cypress prints the summary table, confirms the Test Replay upload, and gives you a Recorded Run link straight to that run in Cloud:

Once the run finishes, the results show up in Cloud. Open a single run, and you get the per-test breakdown, plus a side panel with Test Replay, the video, screenshots, and a Cypress AI summary of what each test was checking:

Running Cypress Cloud in CI/CD

Recording from your laptop is the "try it" step. The real point of Cloud is CI, where you cannot watch the run happen.

The two changes for CI:

1. Do not put the record key in the command. A secret in a build log is a secret leaked. Instead, store it as an environment variable named CYPRESS_RECORD_KEY in your CI provider's secrets. Cypress reads it automatically.

2. The command drops the key:

npx cypress run --record

A minimal GitHub Actions step using the official cypress-io/github-action looks like this:

- name: Cypress run
  uses: cypress-io/github-action@v6
  with:
    record: true
  env:
    CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

On paid plans, CI is also where parallelization earns its keep. Add --parallel to spin up several CI machines targeting the same run, and Cloud balances the specs across them so a 20-minute suite can finish in a few minutes. Higher tiers add spec prioritization (run the specs most likely to fail first) and auto-cancellation (kill the whole run on the first failure to stop burning CI minutes).

This is the same problem Playwright teams solve with sharding. If that is the road you are on, our guide to Playwright sharding covers the equivalent setup.

Cloud's Analytics section is where this pays off over time. The Flaky tests view aggregates every test that failed then passed on retry, scores each one by flaky rate and severity, and charts how flakiness trends day to day:

Under the hood, "flaky" has a precise meaning: a test that fails on one attempt and passes on a retry within the same run. This is why flake detection needs test retries turned on, as the Cypress test retries docs explain. Cypress Cloud surfaces exactly that, attempt by attempt, so you can see the failure and the passing retry side by side instead of guessing:

Cypress Cloud limitations

Cypress Cloud is genuinely useful. It is also where many teams start looking around. The honest list:

1. It is a paid layer on a free tool.

   The runner is open source and free. The visibility that makes a CI suite manageable at scale is not. The free Starter plan records 500 test results per month with 30-day retention, which can be used up quickly on an active team. After that, you are on Team at $67/month and Business at $267/month (billed annually), plus overage charges for every 1,000 extra results. You can check the current numbers on the Cypress pricing page.

   The catch most teams miss is what a "test result" actually is. It is not a spec file or a run; it is each it() block that passes or fails, and it only counts when you record. That detail is the difference between a free plan that lasts and a surprise overage bill.

   

2. You are renting your own test history.

   The data is recorded test results, but it lives in the Cloud on Cloud's retention window. Drop the plan and the history goes with it.

3. It only covers Cypress.

   If part of your suite is in another framework, or you are mid-migration, Cypress Cloud has nothing to say about those runs. It is a single-framework dashboard by design.

4. Cypress itself brings the framework's own limits to the Cloud.

   Cypress runs in the browser, which means no native mobile app testing, JavaScript and TypeScript only, and one browser per test. Those are framework constraints, but they bound what Cloud can ever show you.

None of this makes Cypress Cloud bad. It makes it a commercial product with a pricing model, and at a certain run volume that model is exactly what sends teams to look at the alternatives.

Cypress Cloud alternative

If the per-result bill is what sent you looking, the open-source world covers most of what Cypress Cloud's reporting layer does: 3 options worth knowing, from the lightest to the most platform-like.

Allure Report: rich HTML reports, free

Allure Report is the most widely used open-source test reporting tool, licensed under Apache 2.0. It plugs into Cypress via the allure-cypress adapter and turns a raw run into an interactive HTML report with steps, logs, screenshots, and attachments, all attached to the right test.

Key features:

1. Interactive HTML reports with steps, logs, and media.

2. Historical trend tracking to spot recurring failures.

3. Flaky-test detection and automatic error categorization.

4. Works across 50+ frameworks, so a mixed suite reports in one format.

The trade: Allure generates a static report. There is no hosted dashboard and no live aggregation. You build the HTML each run and host it yourself, or step up to the paid Allure TestOps for the team-server features.

ReportPortal: a real-time, self-hosted dashboard

ReportPortal is an open-source, Apache 2.0 reporting platform you self-host with Docker. It is the closest open-source analog to a hosted dashboard: results from every run aggregate into a single live, centralized view rather than a per-run HTML file.

Key features:

1. Real-time, centralized dashboard across runs.

2. Automated failure analysis that auto-categorizes known versus new failures.

3. Jira and other bug-tracker integrations, with logs correlated to each test.

4. JS agents for Cypress and broad framework support.

The trade: it is a microservice stack. You self-host and maintain the auth, UI, analyzer, and storage services yourself, which is real ops overhead next to a SaaS.

Cypress's built-in reporting: the free baseline you already have

Before reaching for anything, remember cypress run already produces video, screenshots, and machine-readable output (JUnit, JSON) at no cost. It is enough for a single run on one machine.

The trade: there is no cross-run history, no team dashboard, and no flake aggregation. That is the exact gap the two tools above, and the hosted products, exist to fill.

So the real choice among these is how much hosting you want to own: nothing extra (built-in), a static report you publish (Allure), or a live dashboard you operate (ReportPortal).

But there is a different question worth asking before you pick a reporting tool at all.

Sum up: Is Cypress dying?

Every few months someone declares Cypress dead. The honest read is more boring than that: Cypress is not dying, but its center of gravity has shifted.

Here is what is actually happening. Cypress is still widely used, still maintained, and still a genuinely good developer experience for in-browser testing.

At the same time, many teams have moved new work to Playwright for reasons unrelated to Cypress being bad: real multi-browser support, including WebKit; native parallelization without a paid plan; true cross-origin handling; and a faster execution model. If you want the side-by-side, we break it down in Playwright vs Cypress. The searches for "cypress vs playwright" and "cypress to playwright migration” are not a fad. They are a steady stream of migrations, and our Cypress to Playwright migration guide walks through what that move actually entails.

So if you are here searching for a Cypress Cloud alternative, it is worth being honest with yourself about which problem you have:

• "I like Cypress, I just don't want to pay for Cloud." Then an open-source reporter like Allure or ReportPortal covers the reporting, as long as you are willing to host it yourself.

• "I am already rethinking Cypress itself." Then the dashboard question is downstream of a bigger one, and the real move is to look at where your suite is heading.

That second case is where most of the people reading this actually are.

If you are moving to Playwright: Where does TestDino fit

Say the honest version of the situation. You are on Cypress; the Cloud bill or the framework limits pushed you to look around, and Playwright keeps coming up. If you make that move, you trade one problem for another familiar one. Playwright runs your tests beautifully and then hands you the same wall Cypress did: a wall of pass/fail across shards, runs, and branches, with the real failures buried in flaky noise.

That is the gap TestDino is built for. It is the test intelligence layer for Playwright teams running in CI, in the same role Cypress Cloud plays for Cypress, but aimed at the problems that actually eat your week:

1. A red build with no story. ❌ You open the run and see a column of failures with no thread connecting them. TestDino centralizes every Playwright run across shards and branches into one readable dashboard, so "what failed and why" is a glance, not a half-day of digging.

2. Flaky tests nobody trusts. A green suite that goes red on rerun trains the team to ignore red builds. TestDino's flake detection separates real failures from noise, the same problem we dig into in Playwright flaky tests.

3. Triage that takes too long. Trace viewer, grouped errors, and rerun-only-failed cut failure triage from hours to minutes. If you live in traces, Playwright Trace Viewer covers how to get the most out of them.

4. An AI that can read your history. ✅ TestDino's data is agent-callable through an MCP server, so Claude, Cursor, or Copilot can query your historical test patterns directly instead of you grepping logs.

If you are staying on Cypress, TestDino is not your tool, and this guide pointed you at the ones that are. If Playwright is where you are headed, TestDino is the dashboard waiting on the other side. You can start free at testdino.com.

FAQs