---
id: cloud/faq
title: Frequently asked questions (FAQ) in Cypress Cloud
description: Get answers to common questions about Cypress Cloud.
section: cloud
source_path: docs/cloud/faq.mdx
version: 2c5e85057d4c0d411a4a64b0e3254f6c6869a1de
updated_at: '2026-09-03T15:47:52.088Z'
---
# Cypress Cloud FAQ

## General

### What is Cypress Cloud?

[Cypress Cloud](https://on.cypress.io/cloud) gives you access to tests you've recorded - typically when running Cypress tests from your [CI provider](/llm/markdown/app/continuous-integration/overview.md) - and provides you insight into what happened during your tests run.

You can read more [here](/llm/markdown/cloud/get-started/introduction.md).

### What does Cypress record?

Cypress captures the following:

When you run Cypress via `cypress run` passing the `--record` flag the following data is sent to the Cloud for every run:

*   Standard output in the terminal
*   Test results
*   Test definitions
*   Cypress configuration (minus Cypress environment variables)
*   Screenshots
*   Videos
*   OS environment variables related to CI and git information

You have the option to [delete videos or screenshots](/llm/markdown/app/guides/screenshots-and-videos.md#Control-which-videos-to-keep-and-upload-to-Cypress-Cloud) before being sent to the Cloud so those are not captured.

When [Test Replay](#Test-Replay) capturing is enabled, the additional data outlined below will be sent to the Cloud. You can [disable capturing](/llm/markdown/cloud/features/test-replay.md#Opt-out-of-Test-Replay) this data.

*   The rendered DOM and CSS styles for the application under test
*   Cypress commands and events represented in the Command Log
*   Network traffic within your application under test
*   Browser console logs

Cypress Cloud does not capture anything related to the code of your application under test or the code within any associated repositories that are associated with your project.

### How is this different than CI?

Cypress Cloud is **complementary** to your [CI provider](/llm/markdown/app/continuous-integration/overview.md), and plays a completely different role.

It doesn't replace or change anything related to CI. You will still run Cypress tests in your CI provider.

The difference between [Cypress Cloud](/llm/markdown/cloud/get-started/introduction.md) and your CI provider is that your CI provider has no idea what is going on inside of the Cypress process. It's programmed to know whether or not a process failed - based on whether it had an exit code greater than `0`.

[Cypress Cloud](/llm/markdown/cloud/get-started/introduction.md) provides you with the low level details of _what_ happened during your run. Using both your CI provider + Cypress together gives the insight required to debug your test runs.

When a run happens and a test fails - instead of going and inspecting your CI provider's `stdout` output, you can log into [Cypress Cloud](https://on.cypress.io/cloud), see the `stdout` as well as screenshots and video of the tests running. It should be instantly clear what the problem was.

### What counts as a test result?

Which [pricing tier](https://www.cypress.io/pricing) is best for you depends on the number of tests you record each month in your organization.

Tests are recorded when [cypress run](/llm/markdown/app/references/command-line.md#cypress-run) is called with the `--record` flag while supplying the record `--key`. This means your [test run data](/llm/markdown/cloud/features/recorded-runs.md#Latest-Runs) is being "recorded" to Cypress Cloud.

We consider each time the `it()` function is called to be a single test. So you will generally have several tests recorded within each spec file and likely several spec files within a single run. Only the [passed and failed tests](/llm/markdown/app/core-concepts/writing-and-organizing-tests.md#Understanding-test-results) are counted. The pending and skipped tests are NOT counted.

You can always see how many tests you've recorded from your organization's [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md) page within Cypress Cloud.

### What counts as a user?

A [user](/llm/markdown/cloud/account-management/users.md) is anyone with a login to Cypress Cloud who has been invited to see and review the test results of your organization.

Each plan includes a set number of users. To compare the user seats each plan allows, see the [pricing page](https://www.cypress.io/pricing?utm_source=docs.cypress.io&utm_medium=cloud-faq). To see how many of your seats are in use, check the [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md) page in Cypress Cloud.

### How much does it cost?

Please see our [Pricing Page](https://www.cypress.io/pricing) for more details.

### What is the difference between public and private projects?

**A public project** means that anyone can see the recorded runs for it. It's similar to how public projects on GitHub, Travis, or CircleCI are handled. Anyone who knows your `projectId` will be able to see the recorded runs, screenshots, and videos for public projects.

**A private project** means that only [users](/llm/markdown/cloud/account-management/users.md) you explicitly invite to your [organization](/llm/markdown/cloud/account-management/organizations.md) can see its recorded runs. Even if someone knows your `projectId`, they will not have access to your runs unless you have invited them.

### What happens once I reach the test results limit?

Tests running with the `--record` flag will run as normal when the limit is reached, but parallelization will be disabled and new test results will be hidden from the dashboard until your plan is upgraded or a new usage cycle begins. The usage cycle resets at the start of each billing period, which is monthly on most plans, though some annual plans use an annual test results allowance.

In order to avoid any interruption in service, we recommend that you review your usage and select a plan that satisfies your usage requirements. You can do this by:

1.  Logging into [Cypress Cloud](https://cloud.cypress.io)
2.  Select your organization
3.  Navigate to the **Billing and Usage** tab
4.  Review your organization's usage
5.  Scroll down and select **Upgrade** under your plan of choice

### What happens if I downgrade my account?

Downgrading your account will **not** result in loss of access to Cypress Cloud.

However, it will make your Cypress Cloud account subject to the limitations of your new plan. For example, downgrading to the _Starter_ plan will limit data retention to 30 days, test results to 500 per billing period, and your organization to 10 [users](#What-counts-as-a-user).

### When does my billing period reset?

Your usage cycle resets at the start of each billing period, at which point your recorded [test result](#What-counts-as-a-test-result) and AI usage counters return to zero for the new period. Org-level [`cy.prompt`](/llm/markdown/api/commands/prompt.md) execution counts reset on the same schedule. See [cy.prompt](/llm/markdown/cloud/faq.md#cyprompt) for details. Most plans bill monthly, though some annual plans use an annual test results allowance. You can confirm the dates of your current period on your organization's [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md) page.

### How do I reduce my Cypress Cloud usage or lower my bill?

Because Cypress Cloud meters [test results](#What-counts-as-a-test-result) (each passed or failed test recorded with `--record`), the most effective way to reduce usage is to record fewer, more meaningful tests. A few common approaches:

*   Record only the runs you need insight into, rather than every local run.
*   Remove redundant or obsolete tests, and avoid recording the same suite multiple times against the same commit.
*   [Choose the right test level](/llm/markdown/app/guides/test-performance.md#Choose-the-right-test-level) so behavior is covered where it is cheapest to test, instead of duplicating it across many end-to-end tests.
*   [Find and eliminate over-tested UI with UI Coverage](/llm/markdown/app/guides/test-performance.md#Find-and-eliminate-over-tested-UI-with-UI-Coverage) to cut redundant tests that cover the same flows.
*   [Run the right tests at the right time](/llm/markdown/app/guides/test-performance.md#Run-the-right-tests-at-the-right-time), for example a smaller smoke suite on every PR and the full suite less often.
*   Use the **By project** tab on the [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md) page to find which projects consume the most of your plan, then focus there.

For more ways to trim and streamline your suite, see the [Optimizing test performance](/llm/markdown/app/guides/test-performance.md) guide.

If your usage consistently exceeds your plan, compare options on the [pricing page](https://www.cypress.io/pricing); moving to a larger plan is often more cost-effective than purchasing additional test results. You can also **schedule a demo** from the pricing page to talk through the plan that best fits your usage.

### Can I choose not to use Cypress Cloud?

Of course. Cypress Cloud is a separate service from the Cypress app and will always remain optional. We hope you'll find a tremendous amount of value in it, but it is not coupled with being able to run your tests.

You can always run your tests in CI using [cypress run](/llm/markdown/app/references/command-line.md#cypress-run) without the `--record` flag which does not communicate with our external servers and will not record any test results.

## Using Cypress Cloud

### What is the projectId for?

The `projectId` is a 6-character string that helps identify your project once you've [set up your tests to record](/llm/markdown/cloud/features/recorded-runs.md#Latest-Runs). It's generated by Cypress and typically is found in your [Cypress configuration](/llm/markdown/app/references/configuration.md).

*   cypress.config.js
*   cypress.config.ts

```
const { defineConfig } = require('cypress')

module.exports = defineConfig({
  projectId: 'a7bq2k',
})
```

```
import { defineConfig } from 'cypress'

export default defineConfig({
  projectId: 'a7bq2k',
})
```

For further detail see the [Identification](/llm/markdown/cloud/account-management/projects.md#Project-ID) section of the [Cypress Cloud](/llm/markdown/cloud/get-started/introduction.md) docs.

### What is a Record Key?

A _Record Key_ is a GUID that's generated automatically by Cypress once you've [set up your tests to record](/llm/markdown/cloud/features/recorded-runs.md#Latest-Runs). It helps identify your project and authenticate that your project is even _allowed_ to record tests.

You can find your project's record key inside of the _Settings_ tab.

For further details see the [Identification](/llm/markdown/cloud/account-management/projects.md#Project-ID) section of the [Cypress Cloud](/llm/markdown/cloud/get-started/introduction.md) docs.

### How do I record my tests?

1.  First [set up the project to record](/llm/markdown/cloud/get-started/setup.md#Setup).
2.  Then [record your runs](/llm/markdown/cloud/features/recorded-runs.md#Latest-Runs).

After recording your tests, you will see them in [Cypress Cloud](https://on.cypress.io/cloud) and in the Cypress App [Runs](/llm/markdown/app/core-concepts/open-mode.md#Runs) tab.

### Can I delete a run from Cypress Cloud?

You can [archive a run](/llm/markdown/cloud/features/recorded-runs.md#Archive-run) so that it does not display in the runs list or in analytics.

**Note:** Archiving the recorded runs has no effect on the amount of tests recorded and counted as your usage billed for the month.

### Can I host Cypress Cloud data myself?

No. A self-hosted version of Cypress Cloud is not available at this time.

### Why is test parallelization based on spec files and not on the individual functions?

Cypress [test parallelization](/llm/markdown/cloud/features/smart-orchestration/parallelization.md) is indeed based on specs. For each spec, Cypress scaffolds the new running context, in a sense isolating each spec file from any previous spec files, and ensuring a clean slate for the next spec. Doing this for each _individual_ test would be very very expensive and would slow down the test runs significantly.

Spec file durations are also more meaningful and consistent than timings of individual tests, we can order specs by the moving average of the previously recorded durations. This would be much less useful when load balancing quickly finishes individual tests.

Thus, to better load balance the specs, you would want more spec files with approximately the same running duration. Otherwise, a single very long running test might limit how fast all your tests finish, and how fast the run completes. Due to starting a new test execution context before each spec file and encoding and uploading video after, making spec files run shorter than approximately 10 seconds would also be fruitless - because Cypress overhead would eat any time savings.

### My CI setup is based on Docker, but is very custom. How can I load balance my test runs?

Even if your CI setup is very different from the [CI examples we have](/llm/markdown/app/continuous-integration/overview.md#CI-Examples) and [run with our sample projects](https://github.com/cypress-io/cypress-example-kitchensink#ci-status), you can still take advantage of the test load balancing using Cypress Cloud. Find a variable across your containers that is the same for all of them, but is different from run to run. For example, it could be an environment variable called `CI_RUN_ID` that you set when creating the containers to run Cypress. You can pass this variable via CLI argument [`--ci-build-id`](/llm/markdown/app/references/command-line.md#cypress-run-ci-build-id-lt-id-gt) when starting Cypress in each container:

```
cypress run --record --parallel --ci-build-id $CI_RUN_ID
```

For reference, here are [the variables](https://github.com/cypress-io/cypress/blob/develop/packages/server/lib/util/ci_provider.js) we extract from the popular CI providers, and for most of them, there is some variable that is set to the same value across multiple containers running in parallel. If there is NO common variable, try using the commit SHA string. Assuming you do not run the same tests more than once against the same commit, it might be good enough for the job.

### I'm working with a restrictive VPN. Which subdomains do I have to allow on my VPN for Cypress Cloud to work properly?

If you are running the tests from within a restrictive VPN you will need to allow some URLs so that Cypress can have effective communication with Cypress Cloud.

**The URLs are the following:**

*   `https://api.cypress.io` - **Cypress API**, **Studio**, **cy.prompt()**
*   `https://assets.cypress.io` - **Asset CDN** (Org logos, icons, videos, screenshots, etc.)
*   `https://authenticate.cypress.io` - **Authentication API**
*   `https://capture.cypress.io` - **Cypress Test Replay**
*   `https://s3.amazonaws.com/capture.cypress.io` - **Uploading Cypress Test Replay from Test Runner**
*   `https://cloud.cypress.io` - **Cypress Cloud**, **Studio**
*   `https://cloud-api.cypress.io` - **Cypress Cloud CLI** (`cy-cloud`)
*   `https://docs.cypress.io` - **Cypress documentation**
*   `https://download.cypress.io` - **CDN download of Cypress binary**
*   `https://on.cypress.io` - **URL shortener for link redirects**

**If you have enabled Cloud MCP for your organization, you will want to allow it:**

*   `https://mcp.cypress.io` - **Cypress Cloud MCP**

**If you are using GitHub Enterprise or GitLab for Enterprise (Self-managed), you may also need to add the following to the version control IP allowlist:**

*   `3.211.102.119` - **Dedicated IP**
*   `18.213.72.78` - **Dedicated IP**
*   `35.169.145.173` - **Dedicated IP**
*   `44.199.152.70` - **Dedicated IP**
*   `52.70.95.89` - **Dedicated IP**

## Re-run optimization

### Can I rerun only failed tests?

Yes, depending on where you are running tests:

*   **In CI**, [Re-run optimization](/llm/markdown/cloud/features/smart-orchestration/rerun-optimization.md) re-runs only the specs or tests that failed when you trigger a rerun of a recorded build. Choose **Run only failed specs** to re-execute each spec that contained a failure, or **Run only failed tests** (Cypress 15.21.0 or later) to re-execute only the tests that did not pass.
*   **In the Cypress app**, the [Debug page](/llm/markdown/app/core-concepts/open-mode.md#Debug) lets you rerun only the failed tests from a recorded CI run on your current branch.
*   **During a single run**, [test retries](/llm/markdown/app/guides/test-retries.md) automatically re-attempt failed individual tests before the run finishes.

### How is Re-run optimization different from test retries?

They solve different problems. [Test retries](/llm/markdown/app/guides/test-retries.md) automatically retries a failed _individual test_ within a single run, in real time, to absorb flake before the run finishes. **Re-run optimization** changes what happens when you re-run an _entire CI build_ after it has completed, re-executing only the specs or tests that failed. You can use both together: test retries reduce flake within a run, and Re-run optimization speeds up the reruns you still need.

### Does Re-run optimization carry forward my passing test results?

No, not currently. A rerun-optimized run shows only the specs and tests that were re-executed. Work that passed in the anchor run is skipped and does not appear in the rerun's results.

### Why does my CI report show fewer tests after a rerun?

Reporter output (JUnit/XML and custom reporters) reflects only the re-executed specs and tests, so a rerun-optimized run reports fewer specs and tests than a full run. Adjust any CI guardrails that assert on fixed test counts.

### Does Re-run optimization require recording to Cypress Cloud?

Yes. Runs must be recorded to Cypress Cloud with the `--record` flag, and the feature is available on Business or Enterprise plans, or during a free trial.

### What happens if the rerun has no failed specs or tests?

If the anchor run contained no failing specs (or, for **Run only failed tests**, no tests that still need to run), there is nothing to re-execute and the optimized rerun completes without running any specs.

### How do I know Re-run optimization was applied?

The Cypress App prints a notice in the CLI output naming the run it is retrying from. **Run only failed specs** mentions failed specs; **Run only failed tests** mentions tests that did not pass. The run is labeled with a **Re-run** tag in Cypress Cloud.

## Spec Prioritization

### What is Spec Prioritization?

[Spec Prioritization](/llm/markdown/cloud/features/smart-orchestration/spec-prioritization.md) is a [Smart Orchestration](/llm/markdown/cloud/features/smart-orchestration/overview.md) feature that automatically runs the specs that failed in your previous Cypress run first. Instead of waiting for the same failures to resurface late in a run, Cypress Cloud surfaces them right away so you learn whether your latest change worked in minutes rather than at the end of the run.

### Does Spec Prioritization make my tests run faster?

On its own, Spec Prioritization changes the _order_ specs run in, not the total duration, so it surfaces failures earlier without shortening the run. To turn that earlier feedback into shorter runs and lower CI costs, pair it with [Auto Cancellation](/llm/markdown/cloud/features/smart-orchestration/run-cancellation.md): when the prioritized failures reappear at the start of a run, the run is canceled right away, avoiding wasted compute on specs you already know will need another pass.

### What plan do I need to use Spec Prioritization?

Spec Prioritization is available on the [Business and Enterprise tiers](https://cypress.io/pricing). Not sure if upgrading is worth it? The [recommendations](/llm/markdown/cloud/features/recorded-runs.md#Recommendations) on the run overview page predict how much time Smart Orchestration features would save your suite.

### How do I enable Spec Prioritization?

An admin can toggle it on at the project level: open the project in Cypress Cloud, go to **Project Settings**, scroll to the **Smart Orchestration** section, and toggle **Spec Prioritization**. See the [Spec Prioritization guide](/llm/markdown/cloud/features/smart-orchestration/spec-prioritization.md#Enable-Spec-Prioritization) for the full steps.

### How do I know Spec Prioritization took effect?

When Spec Prioritization fires, the run's detail tab displays a **"Prioritized failed specs from run #X"** label, where **#X** links back to the source run whose failures were moved to the front. The label only appears when Cypress Cloud actually reordered specs, so its presence confirms prioritization took effect and lets you trace which previous failures drove the order. If you don't see it, confirm the feature is toggled on and that the previous run recorded failures to prioritize.

## Auto Cancellation

### What is Auto Cancellation in Cypress?

[Auto Cancellation](/llm/markdown/cloud/features/smart-orchestration/run-cancellation.md) is a Cypress Cloud [Smart Orchestration](/llm/markdown/cloud/features/smart-orchestration/overview.md) feature that automatically cancels a recorded run once the number of failed tests reaches a threshold you configure. It stops Cypress from handing out new specs, marks the run as canceled, and reports how much CI time was saved, so you don't pay for tests that run after a run has already failed. It is available on the Business and Enterprise plans.

### How many test failures trigger an auto cancellation?

By default, a single failure cancels the run. You can set a higher threshold in your project's Smart Orchestration settings, or override it per run with the [`--auto-cancel-after-failures`](/llm/markdown/app/references/command-line.md#auto-cancel-after-runs) CLI flag. Only genuinely failed tests count toward the threshold; flaky tests (which fail an attempt but then pass on retry) are not considered and never trigger an auto cancellation.

### Does Auto Cancellation stop tests that are already running?

No. Specs that are already in progress when the threshold is reached finish running so you still get their complete results. Cypress only stops handing out _new_ specs. In a parallelized run, this means machines can keep running the specs they had already started at the moment of cancellation, but none of them will pick up a new spec once the run is canceled.

### How do I disable Auto Cancellation for a single run?

Pass `--auto-cancel-after-failures false` to `cypress run`. This overrides the project setting for that run only, which is useful for important branches that need the full suite to run every time.

### Is Auto Cancellation free?

No. Auto Cancellation is a paid Smart Orchestration feature available on the [Business and Enterprise Cypress Cloud plans](https://cypress.io/pricing).

### What is the difference between Auto Cancellation and manual cancellation?

Auto Cancellation is triggered automatically when a run reaches the configured failure threshold, and the UI labels it _"canceled due to auto-cancellation."_ A manual cancellation happens when a user cancels the run from Cypress Cloud, which the UI labels _"manually canceled"_ and attributes to that user.

### How do I find the tests that triggered an auto cancellation?

The failed tests that triggered the cancellation are the ones counted toward your threshold. The fastest way to reach them is to click the **failed** test indicator in the [run header](/llm/markdown/cloud/features/recorded-runs.md#Run-header), which opens the [Test Results tab](/llm/markdown/cloud/features/recorded-runs.md#Test-Results-tab) pre-filtered to the failures, or to use the [Tests for Review](/llm/markdown/cloud/features/recorded-runs.md#Tests-for-Review) panel, which orders results by failures first. Open a failed test's [detail sidebar](/llm/markdown/cloud/features/recorded-runs.md#Test-detail-sidebar) and [Test Replay](/llm/markdown/cloud/features/test-replay.md) to debug it. Note that a canceled run only includes results for specs that had already started, so it may not contain every failure the full suite would have produced.

## Flaky Test Management

### What is a flaky test?

A flaky test is one that both passes and fails across retry attempts without any change to the code. It fails once, runs again on the same code, and passes. See [Flaky Test Management](/llm/markdown/cloud/features/flaky-test-management.md) for how Cypress Cloud detects and tracks them.

### How does Cypress detect flaky tests?

With [test retries](/llm/markdown/app/guides/test-retries.md) enabled, Cypress Cloud records every retry attempt from your recorded CI runs and flags any test that fails an attempt before ultimately passing as flaky, then scores it by [severity](/llm/markdown/cloud/features/flaky-test-management.md#Flake-severity) based on its flake rate.

### What causes flaky tests?

Flake usually comes from timing issues, race conditions, or differences between your local and CI environments. [Test Replay](/llm/markdown/cloud/features/test-replay.md) lets you compare a passing and failing attempt on the same code to find the cause.

### How do I fix a flaky test?

Open a failing attempt from the flaky test details panel in [Test Replay](/llm/markdown/cloud/features/test-replay.md) to inspect the DOM, network requests, and console at the moment of failure, then compare it against a passing attempt on the same code to pinpoint the root cause.

### How is flake rate calculated?

Flake rate is the share of recent runs affected by flake: the number of runs where the spec had a flaky test divided by the total number of runs in the current window. See [Flake severity](/llm/markdown/cloud/features/flaky-test-management.md#Flake-severity) for how flake rate maps to severity levels.

### Do I need test retries enabled to detect flaky tests?

Yes. [Test retries](/llm/markdown/app/guides/test-retries.md#Configure-Test-Retries) are the fundamental mechanism that lets Cypress Cloud detect flaky tests, so enabling them is required for any Flaky Test Management feature.

### Which Cypress Cloud plan is required for Flaky Test Management?

Flake detection, analytics, and alerting require a [Team Cypress Cloud plan](https://cypress.io/pricing). Enterprise Reporting and the Data Extract API require an Enterprise plan, and [Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) is included on every Cypress Cloud plan.

## Cypress Cloud Account

### What is a Cypress Cloud organization?

A Cypress Cloud organization is the top-level container that groups your [projects](/llm/markdown/cloud/account-management/projects.md), [users](/llm/markdown/cloud/account-management/users.md), [teams](/llm/markdown/cloud/account-management/teams.md), billing and usage, and [integrations](/llm/markdown/cloud/account-management/organizations.md#Integrations). It lets you manage access control and application quality across every project from one place instead of configuring each project individually.

### How do I create an organization in Cypress Cloud?

Open the organization switcher in [Cypress Cloud](https://on.cypress.io/cloud) and click **Create new organization**. A "Default Project" is created automatically, which you can rename and configure in [Project Settings](/llm/markdown/cloud/account-management/projects.md).

### Can I have more than one organization?

Yes. You can create multiple organizations to separate projects by team, business unit, or client, and switch between them using the organization switcher. Usage and [enterprise analytics](/llm/markdown/cloud/features/analytics/enterprise-reporting.md) roll up within each organization.

### Who can manage an organization?

Organization owners and admins can invite users, create teams, configure [Cloud AI](/llm/markdown/cloud/account-management/organizations.md#Manage-Cloud-AI), and set up integrations. Only owners can rename or delete an organization and configure [single sign-on (SSO)](/llm/markdown/cloud/account-management/enterprise-sso.md). See [user roles](/llm/markdown/cloud/account-management/users.md#User-roles) for the full permissions breakdown.

### How do I delete an organization?

You can delete an organization you own once it has no projects. First [delete](/llm/markdown/cloud/account-management/projects.md#Delete-Project) or [transfer ownership](/llm/markdown/cloud/account-management/projects.md#Transfer-ownership) of every project to another organization, then delete the organization from its settings.

### What is my Organization ID?

Your Organization ID is a unique identifier that is linked to your organization. Instructions on how to find your ID are in the [Cypress Cloud Guide.](/llm/markdown/cloud/account-management/organizations.md#Organization-ID)

### What if I can't access my Cypress Cloud account?

1.  If you haven't signed up, see the [Sign Up with an Invitation](/llm/markdown/cloud/account-management/users.md#Sign-Up-with-an-Invitation) instructions.
    
2.  Try resetting your password. If you never received the email, try the following:
    
    *   Try signing in with Google or GitHub
    *   Check the trash and spam folder
    *   Verify it's the correct email address

If the troubleshooting tips above did not resolve the issue or involves SSO, reach out to [support](mailto:support@cypress.io).

### Can I delete my Cypress account?

You can delete your Cypress account from [your Cypress Cloud profile](https://cloud.cypress.io/profile). Deleting your account cannot be undone! By deleting your Cypress account, all associated data in your account will be permanently deleted.

### How do I invite a user to Cypress Cloud?

An organization [Owner or Admin](/llm/markdown/cloud/account-management/users.md#User-roles) can invite users from the **Users & Teams** page by clicking **Invite User**, adding one or more email addresses, and selecting a [role](/llm/markdown/cloud/account-management/users.md#User-roles). Invited users receive an email with a link to accept the invitation. You can also use **Copy invite link** to share your own message. Anyone who joins through that link is given the default **Member** role. See [Invite users](/llm/markdown/cloud/account-management/users.md#Invite-users) for details.

### What are the Cypress Cloud user roles?

Cypress Cloud has five roles that control what a user can see and change: **Viewer** (read-only access to projects and runs), **Member** (the everyday developer role, including record keys and App Quality configuration), **Team Admin** (manages members and settings for their own projects), **Org Admin** (manages all users and both organization and project settings), and **Org Owner** (full control, including billing, SSO, and deletion). See the full [permissions tables](/llm/markdown/cloud/account-management/users.md#User-roles) for an exact breakdown.

### What is the difference between an Org Admin and an Org Owner?

An **Org Admin** can manage all users and edit organization and project configurations, but cannot perform owner-only actions. An **Org Owner** can do everything an Org Admin can, plus invite or edit other owners, set up SSO, edit the organization name, and delete the organization. Only owners can grant other users 'owner' access. See [User roles](/llm/markdown/cloud/account-management/users.md#User-roles).

### Can someone request access to my organization instead of being invited?

Yes. If a teammate already has access to Cypress and your project's source code, they can request to join your organization directly from the Cypress App, and an Owner or Admin can accept or deny the request. This lets you onboard teammates without inviting everyone up front. Note that user requests are not available if your organization is configured for SSO. See [User requests](/llm/markdown/cloud/account-management/users.md#User-requests).

### How do I change a user's email address in Cypress Cloud?

To change a user's email, an **Owner** or **Admin** invites the new email address and removes the previous one. To update your billing email, use the [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md) page or contact [billing@cypress.io](mailto:billing@cypress.io). See [User updates](/llm/markdown/cloud/account-management/users.md#User-updates).

### Does Cypress Cloud support Okta for Government?

Yes. Our Okta integration is a standard SAML 2.0 integration, so Okta for Government uses the same setup steps as commercial Okta. Two values differ: the Identity Provider Single sign-on URL and the X.509 signing certificate, which you need to download from your Okta for Government app because certificates do not transfer between tenants. If you are migrating from commercial Okta, note that we store one SSO configuration per organization, so saving your Okta for Government details replaces the existing configuration. See [Okta for Government](/llm/markdown/cloud/account-management/enterprise-sso.md#Okta-for-Government).

## Teams

### What is a team in Cypress Cloud?

A [team](/llm/markdown/cloud/account-management/teams.md) is a reusable group of users that is granted access to a specific set of projects. Teams let you control project access once at the team level, instead of project by project, user by user, so each person sees only the projects relevant to their work.

### Who can create and manage teams?

Organization [owner or admin](/llm/markdown/cloud/account-management/users.md#User-roles) roles can create teams. Once a team exists, owners, admins, and the dedicated [team admin](/llm/markdown/cloud/account-management/teams.md#Manage-teams) role can configure it by assigning projects and members. The team admin role lets day-to-day team members manage their own projects without routing every request through organization-level admins.

### Do teams affect access to public projects?

No. [Public projects](https://on.cypress.io/what-is-project-access) are visible to all Cypress Cloud users, including those outside of your organization, regardless of team membership. Teams only control access to private projects.

### What is the _Everyone_ team?

Every user in your organization is automatically a member of a default team named _Everyone_, which has access to all projects by default. If you don't need to separate project access, you can leave the _Everyone_ team as-is. When you adopt a team structure, you can remove the _All projects_ assignment from the _Everyone_ team to enforce access through your own teams. See [Manage teams](/llm/markdown/cloud/account-management/teams.md) for setup best practices.

## Debugging

### How do I debug a Cypress test that fails in CI but passes locally?

Record the run to Cypress Cloud, open the failing test, and use [Test Replay](/llm/markdown/cloud/features/test-replay.md) to replay the exact CI run. You can step through the command log and inspect the DOM, network requests, and console logs as they happened in CI, so you can find the difference between your local environment and CI without reproducing the failure on your machine. See the [Debug Failing Tests guide](/llm/markdown/cloud/guides/debug-failing-tests.md) for the full workflow.

### Can I debug a CI failure without reproducing it locally?

Yes. [Test Replay](/llm/markdown/cloud/features/test-replay.md) captures the complete state of each test as it ran in CI and lets you replay it with full debugging capability. This is the primary reason teams use Cypress Cloud for debugging: it removes the need to recreate a CI environment locally.

### How do I know if a test failure is a real bug or just flaky?

Use [Flaky Test Management](/llm/markdown/cloud/features/flaky-test-management.md) to see whether a test has a history of passing on retry, and [Branch Review](/llm/markdown/cloud/features/branch-review.md) to compare your branch against its base and determine whether your change introduced the failure or it already existed.

### Do I need to change my tests to debug them in Cypress Cloud?

No. You only need to [record your runs](/llm/markdown/cloud/get-started/setup.md) with `cypress run --record`. Test Replay, Error Summaries, and the test detail sidebar work automatically, with no changes to your test code.

## Test Replay

### What is Test Replay?

[Test Replay](/llm/markdown/cloud/features/test-replay.md) enables you and your team to troubleshoot and debug failed tests faster. After updating to Cypress `v13`, the new feature will automatically record all browser events and allow you to “replay” what your application under test looked like.

Wind back the clock to any point in an application's test execution and directly interact with tests as they happened in CI. Debug complex problems as if you were there when they first happened. You can:

*   **Inspect the DOM** at the exact time of a test failure to debug tests quickly
*   **View important debugging dimensions** such as network requests, console logs, and more
*   **Save time recreating errors in CI locally** - replay tests as they happened in CI

### How is Cypress Test Replay different from other "replay" services?

There is an important distinction between _session_ replay services (LogRocket, FullStory, DataDog, etc) and Cypress Test Replay. In session replay, user actions are captured as the application is used and delivered back in a replay-able format, usually video or stitched DOM snapshots. These are valuable tools for gathering product insight such as user behavior, per session.

Cypress Test Replay captures every detail of your test runs as they happen in CI. Remember, these tests are running in a headless manner on a virtual machine with no UI being rendered. Sometimes tests will error or fail indicating an issue in your application. Since Cypress Cloud is monitoring the health of your CI test suite, each Test Replay offers a chance to step back in time to analyze and leverage [time travel debugging](/llm/markdown/app/core-concepts/open-mode.md#Time-traveling), network requests, console logs, JavaScript errors, and element rendering to address problems directly. This is incredibly valuable for developer and team productivity. No more hours wasted recreating CI issues on your local machine!

### How much does Test Replay cost?

Nothing. It's free and included in all Cypress Cloud plans.

To get started with Cypress Cloud, [sign up](https://cloud.cypress.io/signup) to start your **30 day free trial** - including all premium Cypress Cloud features and plenty of test results to let you experience the power of Cypress Cloud!

### Can I use Test Replay for tests recorded in different browsers?

Test Replay leverages [Chrome DevTools Protocol(CDP)](https://chromedevtools.github.io/devtools-protocol/), so currently supports Chromium-based browsers (Chrome, Edge, and the deprecated Electron browser) only.

Test Replay would be disabled, with a message that it's only available on Chromium, for tests run in Firefox or WebKit (Safari). You can still record and capture test [artifacts](/llm/markdown/cloud/features/recorded-runs.md#Artifacts) (screenshots, videos and CI logs) via other browsers in separate [run groups](/llm/markdown/cloud/features/smart-orchestration/parallelization.md#Grouping-test-runs).

### Can I replay tests from historical Cypress Cloud runs?

Test Replay is available for tests recorded using Cypress `v13` and up. Tests recorded prior to this will not have Test Replay enabled in Cypress Cloud. You will still have any artifacts collected during the pre `v13` test runs.

### Can I enable or disable Test Replay for specific, individual tests, or is it a global setting? Can I configure my settings so that Test Replay is only enabled for failing test retries?

At this time, users can only opt-out of Test Replay via [project-level settings](/llm/markdown/cloud/features/test-replay.md#Opt-out-of-Test-Replay) in Cypress Cloud. There is no local option for opting out at this time.

### Can I share my test replays?

Yes! You can share Test Replays with any team members who have access to view your Cypress Cloud runs like QA, marketing, design, etc. Open the replay, copy the URL from the browser address bar and pass it along.

### Will Test Replay write any assets to the file system?

Yes, but they are stored in a temporary directory and deleted after the run. There is nothing to `.gitignore`.

### Is the network tab feature available exclusively in Test Replay?

All of the data within Test Replay's Developer Tools in Cypress Cloud (including network events) are already available to you when running tests locally in the Cypress app via your browser's built-in developer tools (e.g. Chrome DevTools). When reviewing a test run that occurred in CI, you can review the network events within Test Replay in Cypress Cloud.

### Can I `console.log()` data in the console view of the Developer Tools panel?

Yes. This displays console logs from within the application under test or your spec files. You may need to use `JSON.stringify(Object)` to display deeply nested data.

### Does Cypress Test Replay network redaction change what I can test?

No, your Cypress tests and assertions are not affected.

### Does network redaction change what I can debug in Cypress Test Replay?

For most tests, no. You keep request timing, status codes, and the structure of each request. If you will need to inspect the redacted value itself in Cypress Cloud, turn redaction off for that project before recording.

### Is network redaction in Cypress Test Replay on by default?

Yes. It applies to every project in Cypress Cloud with Test Replay turned on, with no configuration required.

### Can I redact additional values specific to my application in Cypress Test Replay?

Not today. If you need a value covered that isn't, reach out to your Cypress Cloud account team.

### Do I need a specific Cypress version to get network redaction in Test Replay?

Redaction isn't tied to a specific Cypress version.

### What if I don't want Cypress Test Replay network traffic captured at all?

Turn off Test Replay for that project in Cypress Cloud. This stops capture of the DOM, Command Log, network traffic, and browser console logs.

## Cloud CLI

### What is the Cypress Cloud CLI?

The [Cypress Cloud CLI](/llm/markdown/cloud/integrations/cloud-cli.md) (`cy-cloud`) lets you query your Cypress Cloud data from the command line. You can check the status of a run, read the error and stack trace for a failed test, save a failure screenshot, and pull the [Test Replay](/llm/markdown/cloud/features/test-replay.md) timeline of commands, network requests, and console logs, all without opening a browser. Every command returns JSON, so it works in shell scripts, CI jobs, and AI coding agents.

### How do I install the Cypress Cloud CLI?

Install `@cypress/cloud` globally with your package manager (for example, `npm install --global @cypress/cloud`), then run `cy-cloud login`. You need a Cypress Cloud account, the Cloud CLI integration enabled for your organization, and Node.js `22.21.0` or later. See the [Cloud CLI documentation](/llm/markdown/cloud/integrations/cloud-cli.md) for full setup steps.

### How do I authenticate the Cloud CLI in CI?

Set the `CYPRESS_CLOUD_TOKEN` environment variable to a [personal access token](/llm/markdown/cloud/integrations/cloud-cli.md#Personal-access-token), which you generate from your [Cypress Cloud profile](https://cloud.cypress.io/profile). This authenticates without an interactive `login` step and without writing credentials to disk, and it takes precedence over any stored credentials. Note that `cy-cloud logout` clears stored credentials but does not unset that environment variable.

See [Authenticate the Cloud CLI](/llm/markdown/cloud/integrations/cloud-cli.md#Authenticate) for the full setup, including OAuth and personal access token options.

### How is the Cloud CLI different from Cloud MCP?

Both give programmatic access to your Cypress Cloud data.

[Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) is a remote server your AI client connects to, and the agent selects Cypress tools automatically, which suits conversational, in-editor debugging.

[Cloud CLI](/llm/markdown/cloud/integrations/cloud-cli.md) is a command-line tool for humans, scripts, and terminal-based agents, which suits automation and custom tooling.

Many teams use both.

### Which URL does the Cloud CLI need allowed on a restrictive VPN?

The Cloud CLI communicates with the Cypress Cloud API at `https://cloud-api.cypress.io`, and sign-in also uses `https://cloud.cypress.io`. Add these to your allowlist if you run the CLI behind a restrictive VPN or firewall. See the full list of [URLs to allow](#Im-working-with-a-restrictive-VPN-Which-subdomains-do-I-have-to-allow-on-my-VPN-for-Cypress-Cloud-to-work-properly).

### Which Cypress Cloud plans is the Cloud CLI available on?

The Cloud CLI is available on all Cypress Cloud plans, including the free Starter plan, at no additional cost. An organization admin enables it once from the **Integrations** page in Cypress Cloud.

### Does the Cloud CLI have usage limits?

Yes. Cloud CLI requests are rate limited per user, defaulting to 100 requests per hour, and the same limit applies across all plans. Contact [support@cypress.io](mailto:support@cypress.io) if you need a higher limit.

Rate limits are separate from data availability. What data you can retrieve follows the same recording limits and data retention policies as the rest of Cypress Cloud, which do vary by plan.

### Which version of Cypress do I need to use the Cloud CLI?

The Cloud CLI reads recorded run data from Cypress Cloud, so there is no minimum Cypress app version. You do need to be recording runs to Cloud with `cypress run --record`.

### Do I need to change my tests to use the Cloud CLI?

No. The Cloud CLI reads data your runs already record. You do not modify test code to use it.

### Why am I getting an authentication error from the Cloud CLI?

Confirm you are logged in with `cy-cloud status`. If you authenticate through the `CYPRESS_CLOUD_TOKEN` environment variable, verify the token is set and valid. Remember that `cy-cloud logout` does not unset that environment variable.

### Why can't the Cloud CLI find my run or project?

Verify the Cloud CLI integration is enabled for your organization, and that your Cypress Cloud user has access to the project. The CLI only returns data you can already see in Cypress Cloud.

### What does the Cloud CLI error "Replay not available" mean?

That test does not have Test Replay data available. Confirm [Test Replay](/llm/markdown/cloud/features/test-replay.md) capturing was enabled for the run, and that the run is within your data retention window.

## Cloud AI ✨

### What is Cloud AI?

Cloud AI is part of Cypress AI: capabilities in Cypress Cloud (such as Test Intent Summaries, Error Summaries, and UI Coverage Test Generation) plus AI in the Cypress App ([Studio AI](/llm/markdown/app/guides/cypress-studio.md) and [cy.prompt()](/llm/markdown/api/commands/prompt.md)) when you're connected to Cloud. These capabilities are continuously being added to improve insights and make it easier to accomplish tasks.

See [AI at Cypress](/llm/markdown/cloud/features/cypress-ai-features.md) for the full picture. For [`cy.prompt`](/llm/markdown/api/commands/prompt.md) execution limits, billing, and the grace period, see [cy.prompt](#cyprompt) below.

### Do AI features require a paid plan?

No. Every Cypress AI capability and tool is available without a paid subscription:

*   **No Cypress Cloud account needed:** the [Cypress skills for AI agents](/llm/markdown/app/tooling/ai-skills.md), the [`cypress tap` CLI](/llm/markdown/app/tooling/cypress-tap.md), and [Cypress Studio](/llm/markdown/app/guides/cypress-studio.md) recording (without AI recommendations).
*   **Any Cloud plan, including the free Starter plan:** [`cy.prompt`](/llm/markdown/api/commands/prompt.md), Studio AI recommendations, Test Intent Summaries, Error Summaries, [Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md), and the [Cloud CLI](/llm/markdown/cloud/integrations/cloud-cli.md).
*   **Included with a premium solution:** UI Coverage Test Generation comes with [UI Coverage](/llm/markdown/ui-coverage/get-started/introduction.md), and agent-ready accessibility reports come with [Cypress Accessibility](/llm/markdown/accessibility/get-started/introduction.md).

A paid plan raises limits rather than unlocking capabilities: a larger `cy.prompt` execution allowance and higher hourly limits for `cy.prompt` and Studio AI. See [AI usage limits](/llm/markdown/cloud/features/cypress-ai-features.md#Usage-limits).

## cy.prompt

### What is a cy.prompt execution?

Every time a [`cy.prompt`](/llm/markdown/api/commands/prompt.md) command runs, in open mode or run mode, that counts as a single cy.prompt execution. Usage is treated consistently whether you are authoring and running tests locally or in CI runs.

As an example: if a test suite includes 3 `cy.prompt` commands in the test code and they are each invoked exactly once, each full run of that suite consumes 3 `cy.prompt` executions.

Track usage on your organization's [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md#Prompt-executions) page. For migrating from `cy.prompt` to regular Cypress code, see the [App FAQ](/llm/markdown/app/faq.md#cyprompt).

### What is AI self-healing?

[`cy.prompt`](/llm/markdown/api/commands/prompt.md) self-heals a step when the element it needs has changed since the step last ran, so tests keep passing as the UI evolves. When possible, the step may self-heal from a cache of previously-successful selectors for the element referenced in that spec. If no good selector exists, `cy.prompt` will create a new one using AI to find the appropriate element. See [Self-healing](/llm/markdown/app/guides/ai-test-generation.md#Self-healing) in the AI Test Generation guide.

### What are the cy.prompt usage limits?

Beyond your plan's execution allowance, `cy.prompt` has two additional sets of limits.

**Per-user hourly limits** apply only to runs that are not recording to Cypress Cloud:

*   Free accounts: 100 prompts per hour per user, and 500 prompt steps per hour per user.
*   Paid accounts (or on a free trial): 600 prompts per hour per user, and 3,000 prompt steps per hour per user.

**Per-prompt limits** apply to every `cy.prompt` call:

*   Up to 50 steps per call, to maintain context fidelity and produce reliable, executable commands.
*   System-wide limits apply to the total input length. Very long prompts may be rejected or require splitting. To stay within these limits, keep one action or assertion per step and split long flows into multiple `cy.prompt` calls.

### My organization shows that it is over the limit during the `cy.prompt` grace period, will I be charged anything for this?

No. There are no charges or limiting behavior related to any usage prior to the August 1, 2026 cutoff.

### What happens at the end of the `cy.prompt` grace period?

Your accumulated usage from before August 1, 2026 will be fully ignored for billing purposes. On August 1, 2026, your organization will start with a count of zero `cy.prompt` executions consumed. You will see a limit that matches your plan and is pro-rated to your contract term.

For example, if you have 6 months remaining on your plan on August 1, 2026, and the plan has 2,000 built-in cy.prompt executions for the year, you would have 1,000 executions available.

### What happens when I exceed my allowed limit of cy.prompt executions?

You will see warnings in the Cypress Cloud UI as you approach your limit, and after you cross it.

On a paid plan:

*   Your tests and `cy.prompt` will run normally. You will not be automatically charged for prompt executions over your plan's limit.
*   If you regularly go over your limit, we ask that you update your plan to match your usage.

On a free plan:

*   AI self-healing and new prompt creation will be turned off for the rest of your monthly billing cycle.
*   When your plan renews, these features will work again.

### What happens when AI is disabled for my organization?

Existing prompt commands and steps will continue to execute, but operations that require AI to function will fail. This includes most self-healing behavior and the creation of new prompt commands.

Organization admins and owners can enable or disable AI capabilities from [organization settings](/llm/markdown/cloud/account-management/organizations.md#Manage-Cloud-AI).

### When does my usage reset?

Usage is tracked similar to test results and resets on the same schedule with the start of the billing period for your existing plan. See [When does my billing period reset?](#When-does-my-billing-period-reset) and your organization's [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md) page for dates.

### Can I buy increased limits?

You can upgrade your plan to gain increased execution limits, along with the other benefits of higher-level plans. See [Cypress Cloud plans](https://www.cypress.io/pricing?utm_source=docs.cypress.io&utm_medium=cloud-faq) for details.

Reach out to your Cypress representative if you have questions about this, or if you are on a plan where a self-serve upgrade is not an option for you.

### Can I be notified of usage approaching limits?

Yes. On the [Billing & Usage](/llm/markdown/cloud/account-management/billing-and-usage.md#Usage-notification) page, you can set thresholds for email alerts based on usage, similar to the ones you already get for test management.

### What limitations does cy.prompt have?

See the [Limitations](/llm/markdown/api/commands/prompt.md#Limitations) section in the [`cy.prompt` API reference](/llm/markdown/api/commands/prompt.md) to learn what commands and other techniques are not supported.

Review the steps of your generated tests to confirm they are behaving as intended, especially if attempting steps that are documented as not supported.
