How to Get Better Visibility into Cypress Test Results

For better visibility into Cypress test results, combine four layers: inspect the run in the Cypress Test Runner and terminal, publish a structured report such as JUnit XML to CI, retain screenshots and optional video for failures, and use Cypress Cloud when you need centralized history across runs. These layers work together: a team can publish JUnit results while preserving artifacts and recording runs in Cloud.

1. Diagnose a run locally

Use cypress open when you need to watch a test interact with the application, inspect commands, and reproduce a failure. Use cypress run for a headless or CI-style run that writes results to the terminal and can capture failure screenshots and video.

npx cypress open
npx cypress run

Cypress uses the spec reporter by default and writes its output to standard output. It shows test outcomes as the run proceeds, which is often the fastest starting point for understanding where a local run failed. The [Cypress reporter guide](https://docs.cypress.io/app/tooling/reporters) documents the default and other reporter options.

2. Publish structured results to CI

When you want a CI interface to display individual test outcomes, emit JUnit XML and configure that CI provider to ingest the report. Reporter output alone does not configure CI ingestion; follow the provider’s instructions for locating and publishing the generated XML.

Configure JUnit through the CLI

npx cypress run --reporter junit --reporter-options "mochaFile=results/junit-[hash].xml,toConsole=true"

The [hash] placeholder gives separate spec files distinct output names. Without unique names, a static mochaFile path can be overwritten as multiple specs run, leaving only the last spec’s report. Create the output directory before running if your environment does not create it automatically, and configure your CI provider to collect the resulting files.

Set reporter options in Cypress configuration

You can make the reporter configuration persistent in cypress.config.js (or the equivalent TypeScript config):

const { defineConfig } = require('cypress')

module.exports = defineConfig({
  reporter: 'junit',
  reporterOptions: {
    mochaFile: 'results/junit-[hash].xml',
    toConsole: true,
  },
})

Then run:

npx cypress run

Cypress also includes the teamcity reporter, and supports Mocha reporters because Cypress is built on Mocha. Pick the format your CI system can ingest, and check the reporter documentation for supported options and current behavior.

3. Create a standalone HTML report

If readers need a shareable report outside the CI interface, Cypress documents a Mochawesome workflow: write one JSON file per spec, merge the JSON files, then generate HTML. Install the reporter and utilities as development dependencies:

npm install --save-dev mochawesome mochawesome-merge mochawesome-report-generator

Run Cypress to produce per-spec JSON, merge the files, and generate the HTML report:

npx cypress run --reporter mochawesome --reporter-options "reportDir=mochawesome-report,json=true,html=false,overwrite=false"
npx mochawesome-merge "mochawesome-report/*.json" -o mochawesome-report/report.json
npx marge mochawesome-report/report.json -o mochawesome-report

Keep per-spec output unique and avoid overwrite behavior that discards earlier results. Make sure the merge step reads only the JSON files for the current run; otherwise stale files from a previous run can contaminate the report. See the [Cypress reporter guide](https://docs.cypress.io/app/tooling/reporters) for its Mochawesome example and configuration details.

4. Preserve failure screenshots and video

During cypress run, Cypress automatically captures screenshots when tests fail. By default, screenshots are written to cypress/screenshots. Cypress does not automatically capture failure screenshots in cypress open. Video recording is disabled by default; when enabled, Cypress records run-mode specs and stores videos in cypress/videos by default.

// cypress.config.js
const { defineConfig } = require('cypress')

module.exports = defineConfig({
  video: true,
})

Configure your CI job to upload the screenshot and video folders as artifacts, and set an intentional retention period in the CI system. Cypress clears screenshots and videos before a run by default. If your workflow depends on existing files, review the trashAssetsBeforeRuns configuration and artifact handling. The [screenshots and videos guide](https://docs.cypress.io/app/guides/screenshots-and-videos) covers capture behavior, folders, and configuration.

5. Track runs and artifacts in Cypress Cloud

For centralized run history, invoke Cypress with --record and a record key. Cypress Cloud’s recorded-run views can include test results, terminal output, screenshots, and videos, and provide historical views for failed, flaky, and modified tests. This is useful when an isolated CI log is not enough to see how failures evolve across runs.

npx cypress run --record --key YOUR_RECORD_KEY

Keep the key in your CI secret store rather than committing it to source control. Review the [recorded runs documentation](https://docs.cypress.io/cloud/features/recorded-runs) and [Cloud FAQ](https://docs.cypress.io/cloud/faq) for setup and recorded data details. Cloud is a hosted workflow, so check your team’s data handling needs and plan limits before recording. Cypress documents storage and masking controls in its [data storage and masking guide](https://docs.cypress.io/cloud/account-management/data-storage-and-masking).

6. Choose a visibility setup

Need	Useful layer	What to configure
Understand a failure while developing	Test Runner and terminal	Run `cypress open` for interactive diagnosis or `cypress run` for run output.
See individual outcomes in CI	JUnit or TeamCity reporter	Write report files and configure CI report ingestion.
Share a formatted report	Mochawesome HTML	Generate unique per-spec JSON, merge it, and create HTML.
Inspect failure behavior after the job ends	Screenshots and optional video	Enable video if useful, upload artifacts, and set retention.
Compare runs over time	Cypress Cloud	Record runs and review centralized history and artifacts.

These choices are complementary. For example, JUnit can provide CI annotations while the same workflow uploads failure screenshots and records a run in Cloud.

7. Troubleshoot common reporting problems

Symptom	Likely cause	Fix
Only one spec appears in the JUnit report	Multiple specs wrote to the same static `mochaFile`.	Use a unique filename pattern such as `[hash]`; merge reports if the CI workflow needs one file.
CI shows no tests even though Cypress passed or failed	The reporter output was not configured, or the CI provider did not ingest the XML path.	Confirm the JUnit reporter runs, inspect the generated XML, and configure the CI system’s report collection step.
No screenshot appears after a local interactive failure	Automatic failure screenshots are associated with `cypress run`, not `cypress open`.	Reproduce with `npx cypress run` if you need the automatic failure artifact.
No video file exists	Video is disabled by default, or the run used `cypress open`.	Set `video: true` and use `cypress run`.
Old artifacts disappear or reports include unexpected files	Cypress clears screenshot and video folders before runs by default, or a report merge glob includes stale JSON.	Review `trashAssetsBeforeRuns`, use a clean per-run report directory, and upload artifacts before cleanup.
Cloud history is missing	The run was not recorded or the record key/configuration is unavailable.	Run with `--record` and a valid key, and check CI secrets and Cloud setup.

8. Performance, reliability, and data handling

Keep the default path simple: terminal output and JUnit files are low-friction ways to make a run inspectable. Add HTML generation only when a standalone report is useful.
Account for artifact volume: videos and screenshots add files to CI storage and upload time. Preserve the evidence your team uses, and set retention deliberately.
Make multi-spec output deterministic: unique report filenames prevent overwrites; a clean output folder prevents stale data from being merged into a new run.
Preserve the diagnostic chain: retain the test report alongside screenshots or video so a failure’s test identity can be matched to its visual evidence.
Check hosted-data requirements: recorded Cloud runs may include CI and Git metadata as well as test output and artifacts. Review Cypress’s documented masking and storage controls and your own obligations before enabling recording.
Avoid unsupported savings claims: the reviewed documentation does not establish a general time-saving or performance figure for these reporting approaches. Choose based on the visibility and data controls your workflow needs.

9. Optional integrations and UI coverage

Cypress’s plugins catalog lists community integrations such as allure-cypress, cypress-terminal-report, cypress-mochawesome-reporter, and ReportPortal’s Cypress agent. These are options to evaluate, not endorsements. Check current maintenance, Cypress compatibility, and CI requirements before adopting one. See the [Cypress plugins catalog](https://docs.cypress.io/app/plugins/plugins-list).

If your question is which pages or components your tests cover, rather than why a test passed or failed, Cypress UI Coverage is a separate visibility layer. Its setup uses Cypress Cloud with Test Replay and describes monitoring changes through a Results API. Consult the [UI Coverage setup guide](https://docs.cypress.io/ui-coverage/get-started/setup) to determine whether that fits the coverage question.

Or skip the browser setup

If the visibility problem includes capturing a page as evidence, [ScreenshotNeo](https://screenshotneo.com) is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF; see the [API documentation](https://screenshotneo.com/docs/) for options and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers report the page verdict and billing status.
An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs.
The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots.

FAQ

Can I use JUnit and Cypress Cloud together?

Yes. JUnit can feed CI test-result views while Cloud records runs and artifacts for centralized history.

Does Cypress take failure screenshots in the interactive Test Runner?

Automatic failure screenshots are captured during cypress run; they are not automatically captured during cypress open.

Is video necessary for useful failure visibility?

No. Start with test output and failure screenshots. Enable video when the sequence of browser actions would help diagnose intermittent or timing-sensitive behavior.

When is UI Coverage relevant?

Use it when you need to understand UI page or component coverage across runs. It serves a different question from ordinary pass/fail reporting.