Cypress vs. Playwright: Debugging Tests Compared

Cypress and Playwright both give you ways to inspect a failing browser test locally and preserve evidence from CI. Cypress centers local debugging on its interactive Test Runner and Command Log. Playwright offers UI Mode, Inspector, and Trace Viewer. The practical choice depends on which evidence helps diagnose your team’s common failures with the least setup: application state around a command, action and locator details, network activity, or a shareable recorded run.

Neither tool’s documentation establishes that it is universally easier or faster to debug. Compare the workflows against a representative failure from your own test suite.

1. Quick comparison

Debugging need	Cypress	Playwright
Explore a test locally	Open mode runs specs in the interactive Test Runner, with the app or component visible beside the Command Log.	UI Mode runs and explores tests with a test list, filters, timeline, action details, and snapshots.
Inspect a failure step	Hover or pin a Command Log entry to inspect the app state at that point; some actions show before and after snapshots.	Use UI Mode’s action timeline and DOM snapshots, or Inspector to step through actions and inspect locators and actionability.
Understand browser activity	The Command Log includes page events and XHR/fetch requests; intercepts, stubs, and spies add inspection panels.	UI Mode has a Network tab with request and response details, plus browser and test console output.
Diagnose CI failures	Test Replay in Cypress Cloud can replay a recorded CI run with network, console, and DOM-snapshot evidence.	Trace Viewer opens a trace with a timeline, per-action DOM snapshots, network requests, and more.
Capture overhead	Review the setup, access, retention, and service requirements for your chosen CI evidence workflow.	Playwright advises capturing traces on the first retry in CI; tracing every test can be performance heavy.

These descriptions summarize each vendor’s documentation. They are not a controlled comparison of debugging time or cost.

2. Debug a Cypress test locally

Cypress’s local interactive workflow is open mode. The Test Runner executes commands step by step, displays the application or component under test, and streams test commands and hooks into the Command Log. Hovering over a command restores the application state from when it ran; pinning keeps that snapshot available while you inspect it. Some action commands show multiple snapshots, such as before and after a click or input change. The log also records page loads, URL changes, form submissions, and XHR/fetch requests.

Open the Cypress app and run the failing spec in open mode.
Find the failed command in the Command Log. Hover over nearby commands to inspect the state leading up to the failure; pin a useful snapshot if you need to compare it with later state.
Inspect console details and recorded page or network events around the command.
For requests that affect the page, use cy.intercept() and inspect the route, stub, spy, or function call in the instrument panel.
Use .debug(), cy.pause(), browser DevTools, or a debugger statement when the snapshot and log do not expose the state you need.

There is an important execution detail: Cypress commands are queued and run later. JavaScript after a queued Cypress command does not necessarily execute at the moment its source position suggests. A debugger placed after queued commands can therefore behave differently from ordinary sequential JavaScript. Use Cypress’s debugging aids with the command queue in mind.

For flaky tests, Cypress recommends asserting around required steps and making sure a network request has completed before asserting on DOM content that depends on it. Differences between local and CI environments can also explain failures.

3. Debug a Playwright test locally

Explore with UI Mode

Launch the interactive test interface with:

npx playwright test --ui

UI Mode lets you explore, run, watch, and debug tests, and filter by name, project, tag, or result. Its timeline lets you step through actions and view snapshots. The Actions tab shows locators and durations; DOM snapshots can be opened separately. UI Mode also surfaces source highlighting, errors, browser and test console output, and a Network tab with request and response details.

Step through a test with Inspector

Run a specific test in debug mode:

npx playwright test path/to/example.spec.ts --debug

This opens the Inspector and a headed browser. In this mode, Playwright documents a default timeout of zero. The Inspector supports stepping, selecting and editing locators, reviewing actionability logs, and setting breakpoints. You can also add await page.pause() where you want execution to stop, or use the Playwright VS Code extension to debug from the editor.

Use UI Mode when you want to explore a run and its evidence. Use Inspector when you want to follow execution step by step, refine a locator, or understand why an action was not actionable.

4. Diagnose failures from CI

Playwright: save a trace for a retry

Playwright’s best-practices guidance recommends Trace Viewer for CI failures instead of relying only on screenshots or video. A trace provides a timeline, per-action DOM snapshots, network requests, and additional run details. Configure tracing in the Playwright config and, following the documented guidance, capture a trace on the first retry in CI. Tracing every test can add significant performance overhead.

Open the trace from the HTML report to inspect the action sequence and the evidence around a failure. Decide how your CI system will retain the report and trace artifacts long enough for developers to investigate them.

Cypress: replay a recorded run

Cypress documents Test Replay in Cypress Cloud as a way to inspect a test as it ran in CI. Its replay information can include network requests, console output, and DOM snapshots, and replay links can be shared. Check your team’s Cypress Cloud setup, access, and plan requirements when deciding whether this fits your workflow.

The operational comparison is about how evidence is configured, retained, opened, and shared. A hosted replay and a trace artifact have different setup and access considerations; choose based on your team’s CI practices rather than assuming either is frictionless.

5. Choose based on the failure you need to explain

The page changed unexpectedly after an action: Cypress’s command-linked snapshots are useful for checking state around commands. Playwright UI Mode also offers before/after DOM snapshots and an action timeline.
A request or response is involved: Inspect Cypress’s recorded XHR/fetch activity and intercept instrumentation, or Playwright UI Mode’s Network tab and trace network evidence.
A locator or actionability problem is involved: Playwright Inspector is built for stepping, locator selection, and actionability logs. In Cypress, inspect the command and page state, then use its pause/debug tools and DevTools as needed.
The failure only occurs in CI: Compare the run evidence from Playwright Trace Viewer or Cypress Test Replay, and check for local/CI environment differences.
Your team needs to share a diagnosis: Compare the trace artifact workflow with the replay links and access model available to your Cypress Cloud setup.

Before standardizing, take one recurring or representative failure and have developers diagnose it using the workflow you are considering. Check whether it exposes the needed DOM, console, network, action, and source evidence, then account for configuration, capture overhead, retention, and service access. Feature availability alone does not prove that a tool reduces debugging time.

6. Troubleshooting common debugging problems

Symptom	Likely cause	What to try
A Cypress `debugger` statement does not stop where expected.	Cypress commands are queued and execute later, so source order is not the same as ordinary synchronous execution.	Use `.debug()`, `cy.pause()`, or DevTools at the relevant point, and reason about when queued commands run.
A Cypress assertion fails before the page has data.	The DOM assertion depends on a request that has not completed.	Intercept or otherwise wait for the required request, then assert on the resulting DOM state.
A failure is visible locally but hard to explain from CI output.	The CI run may not have retained a trace or replay, or its evidence may not include the relevant signals.	Configure Playwright trace capture for an appropriate retry, or review Cypress Test Replay availability and setup. Retain the resulting evidence with the CI run.
A Playwright debug run waits indefinitely.	`--debug` uses a zero default timeout.	Step through the Inspector and stop the run when done; do not interpret the debug-mode wait as the normal test timeout behavior.
Trace capture slows the CI suite.	Capturing traces for every test can be performance heavy.	Follow Playwright’s recommendation to capture on the first retry in CI, then assess whether the saved evidence is sufficient.
A test fails only in CI.	Local and CI environments may differ in browser, data, timing, or other conditions.	Use the run’s replay or trace evidence to locate the divergence, then compare the environments and ensure required requests complete before dependent assertions.

7. Performance, reliability, and cost considerations

Local debugging: Interactive runners and headed browsers are for investigation. They change the way you observe a test; they are not evidence that the test will be more reliable in CI.
Trace overhead: Playwright explicitly cautions that tracing every test is performance heavy. Capture evidence selectively, such as on the first retry in CI, and review how that affects your own pipeline.
Flakiness: Better evidence can reveal timing, request, or environment problems, but it does not fix them automatically. Wait for the dependency the assertion actually needs and compare local and CI conditions.
Retention and access: Include artifact storage and retention for Playwright traces in your CI workflow. For Cypress Test Replay, check the Cypress Cloud setup and access or plan constraints that apply to your team.
Comparative claims: The cited documentation describes features and recommendations, not vendor-neutral benchmarks. Measure your own failure diagnosis and pipeline overhead if those numbers matter to your decision.

8. Take a screenshot while investigating a browser issue

A screenshot can help document a visual state in a bug report or investigation. For repeatable page capture through an API, ScreenshotNeo is a website screenshot API and MCP server for developers. It is an alternative to try first when you need a clean page image: it accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture. Each of those steps can be turned off.

ScreenshotNeo’s API returns an image or PDF from a GET request. Its response identifies the page verdict and billing status in headers; bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing. It also offers an MCP server with take_screenshot, get_page_info, and capture_pdf tools for AI agents using Claude, Cursor, or another MCP client.

For this Cypress and Playwright comparison, screenshots are supplementary documentation: they do not replace the command history, DOM snapshots, network evidence, or traces needed to diagnose a test failure.

Or skip the browser setup

Use the API call below to save a screenshot. Replace the example URL with the page you want to capture and put your API key in the request. See the ScreenshotNeo API documentation for its options.

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}`);

ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

9. Frequently asked questions

Is Cypress or Playwright better for debugging?

It depends on the failure and your team’s workflow. Compare Cypress’s command-centered snapshots with Playwright’s UI Mode, Inspector, and trace workflows using a representative failure.

Which Playwright tool should I open first?

Start with UI Mode to explore a run and its timeline. Use Inspector when you need to step through execution, refine a locator, or examine actionability.

Can a screenshot explain a flaky test by itself?

Usually it shows only a rendered moment. A timing or request failure may also need command history, network evidence, console output, or a trace/replay.

Should I record every test run?

Not by default. Playwright warns that tracing every test can be performance heavy and recommends trace capture on the first retry in CI. Choose evidence capture based on the diagnostic value and overhead your pipeline can support.