Cypress Logging: A Guide to Debugging and Visibility

Understanding Logging in Cypress

Logging in Cypress provides visibility into how tests execute and how the application behaves at each step. Unlike traditional automation tools, Cypress automatically captures detailed execution logs, making it easier to trace failures and understand test flow.

Cypress logs every command it runs, along with the current application state and DOM snapshot. These logs appear in the Cypress Test Runner and allow testers to inspect what happened before and after each action. This built-in logging removes much of the guesswork typically involved in UI test debugging.

In addition to Cypress command logs, testers can use browser-level logs to inspect values, application state, and JavaScript execution.

Using cy.log() in Cypress

cy.log() is a Cypress command used to add custom messages to the Command Log, helping testers understand test flow and debug failures more effectively. It is especially useful when you want to highlight key actions or add context during test execution.

What cy.log() Does

• Displays custom messages in the Cypress Test Runner
• Executes in sequence with other Cypress commands
• Helps annotate test steps and clarify intent

When to Use cy.log()

• To mark important checkpoints in a test
• To add context before or after critical actions
• To log values that influence test behavior
• To make debugging easier during local runs

Logging Dynamic Values

Since Cypress commands are asynchronous, dynamic values should be logged inside a then() callback:

• Extract text or attributes from the DOM
• Log values returned from API responses
• Log computed variables used in assertions

Cypress Command Log Explained

The Cypress Command Log is the primary place to understand how a test executes step by step. It automatically records every Cypress command and assertion, giving testers clear visibility into test behavior and application state during execution.

What the Command Log Shows

• Each Cypress command in the order it runs
• Command status (passed, failed, retried)
• The subject yielded by each command
• Automatic retries and waiting behavior

Using Command Logs for Debugging

• Clicking a command shows a DOM snapshot of the application at that step
• Testers can inspect element state, attributes, and text at any point
• Failed assertions highlight exactly where and why the test broke

Time Travel and Execution Flow

• Cypress captures snapshots after every command
• You can move backward and forward through test steps
• This helps identify timing issues, UI changes, or unexpected state transitions

Why the Command Log Is Important

• Eliminates guesswork during debugging
• Makes asynchronous behavior easier to understand
• Provides more insight than traditional console logs

The Cypress Command Log is one of the framework’s strongest debugging tools, enabling faster root-cause analysis and more reliable test maintenance.

Logging with console.log() in Cypress

console.log() can be used in Cypress tests to print values to the browser’s developer console or terminal output during headless execution. It is useful for inspecting raw JavaScript values and application state that are not directly visible in the Cypress Command Log.

How console.log() Works in Cypress

• Logs output to the browser DevTools console during interactive runs
• Appears in terminal output when tests run in headless mode
• Executes immediately as JavaScript runs, not as a Cypress command

When to Use console.log()

• To inspect variables or objects outside Cypress commands
• To debug application-side JavaScript logic
• To log values inside callbacks such as then()

Common Pitfalls

• Logging Cypress command results directly will not work as expected
• Logs may appear out of order due to Cypress’s asynchronous execution model
• console.log() does not appear in the Cypress Command Log

Debugging with .debug() and .pause()

Cypress provides .debug() and .pause() to help testers inspect application state during test execution. These commands are especially useful when diagnosing flaky behavior or understanding complex UI flows.

Using .debug()

• Prints the current subject to the browser’s DevTools console
• Allows inspection of elements, properties, and values at a specific step
• Commonly chained after commands like cy.get() or cy.find()
• Helps verify whether the correct element or value is being yielded

Using .pause()

• Pauses test execution at a specific point
• Allows stepping through subsequent commands manually
• Enables interactive inspection of the application state in the Test Runner
• Useful for understanding timing issues or unexpected UI behavior

When to Use These Commands

• Investigating flaky or intermittent failures
• Validating element state before assertions
• Exploring complex user flows step by step

When used correctly, .debug() and .pause() provide powerful insight into test execution without modifying application code.

Logging Network Requests and Responses

Logging network activity is essential when debugging issues related to API calls, asynchronous data loading, or backend-dependent UI behavior.

Cypress provides built-in support for observing and controlling network requests, making it easier to understand how the application communicates with backend services during test execution.

Using Network Interception for Logging

• Cypress can intercept HTTP requests and responses during a test run
• Intercepts allow visibility into request methods, URLs, headers, and payloads
• Responses can be inspected to validate status codes and data returned

What You Can Log from Network Calls

• Request URLs and HTTP methods
• Request payloads and headers
• Response status codes and response bodies
• Timing and sequence of API calls

Why Network Logging Is Useful

• Helps diagnose UI failures caused by backend issues
• Makes it easier to debug flaky tests caused by slow or failed API calls
• Allows validation that the correct requests are triggered at the right time

Network logging gives testers deeper insight into application behavior and helps isolate whether failures originate in the UI or backend services.

Accessing and Logging Test Data

In Cypress, test data often comes from the UI (DOM text/attributes), fixtures, environment variables, or API responses. To log this data reliably, it’s important to understand how Cypress commands yield values and how to access those values at the right time.

Common Sources of Test Data

• DOM values: text, attributes, input values, element count
• Fixtures: static JSON data used for predictable tests
• Environment variables: URLs, credentials, feature flags
• API responses: values returned from intercepted or requested endpoints

How to Access Values Correctly

Cypress commands don’t return values directly; they yield values asynchronously. To access and log data:

• Use then() to work with the resolved value after a Cypress command completes
• Extract the data you need (text, attribute, response body)
• Log it using cy.log() or console.log() depending on where you want it to appear

What to Log (and What Not to)

Good candidates to log

• Key identifiers used in the flow (order ID, username, status)
• Response status codes or critical response fields
• Values that explain why an assertion failed

Avoid logging

• Sensitive data (tokens, passwords, personal data)
• Large response bodies unless necessary
• Repetitive values that clutter logs

Accessing and logging test data the right way makes debugging faster and helps you understand whether failures are due to wrong test data, UI state, or backend responses.

Viewing Logs in CI and Headless Runs

When Cypress tests run in CI pipelines or headless mode, logs are no longer visible in the interactive Test Runner. Understanding where logs appear and how to access them is essential for diagnosing failures in automated environments.

Where Cypress Logs Appear in Headless Runs

• Terminal output: Cypress prints command results, errors, and console.log() output directly to the CI or terminal logs.
• Screenshots: Automatically captured when a test fails, showing the UI state at the point of failure.
• Videos: Recorded during headless execution, allowing replay of the full test run.
• Network and application logs: Available through CI artifacts or integrated logging tools, depending on setup.

Logging Considerations for CI

• Use clear and meaningful cy.log() messages to provide context in failure analysis.
• Rely on assertions and network intercepts instead of excessive logging.
• Ensure logs do not expose sensitive data such as tokens or credentials.

Proper use of logs in CI and headless runs helps teams debug faster, reduce pipeline failures, and maintain confidence in automated test results.

Cypress Logging Best Practices

Effective logging helps debug Cypress tests faster without adding noise. Here are some best practices to follow:

• Log with Intent: Only log information that explains test behavior or helps diagnose failures. Unnecessary logs make real issues harder to spot.
• Prefer Cypress Logs Over Console Logs: Use cy.log() for visibility in the Cypress Test Runner. Reserve console.log() for inspecting raw JavaScript values when needed.
• Log Resolved Values Only: Cypress commands are asynchronous, so always log values inside then() blocks to ensure the data is available.
• Avoid Noisy or Redundant Logs: Logging every step or static values clutters output and slows debugging. Keep logs focused on critical points.
• Never Log Sensitive Data: Avoid printing credentials, tokens, or personal data in logs, especially in CI environments where logs are shared.
• Combine Logs with Assertions: Logs provide context, while assertions enforce behavior. Use logs to explain failures, not replace validations.
• Use Logging to Investigate Flakiness: Log network responses and UI state around flaky steps to identify timing or async issues instead of adding hard waits.

Common Cypress Logging Mistakes

Even experienced testers can misuse logging in Cypress, leading to confusion, noisy output, or hidden issues. Understanding these common mistakes helps avoid ineffective debugging and unreliable tests.

• Logging Cypress Commands Directly: Cypress commands don’t return values immediately, so logging them directly results in undefined or misleading output. Always log resolved values instead.
• Logging Outside the Cypress Command Chain: Using logs outside Cypress commands can cause them to run before values are available. This often leads to logs appearing out of order or missing data.
• Overusing Logs Instead of Assertions: Logs should explain what happened, not replace checks. Relying on logs instead of assertions can allow tests to pass even when behavior is incorrect.
• Adding Logs to Mask Timing Issues: Using logs as a workaround for flaky tests hides synchronization problems. Proper waits and assertions should be used instead.
• Logging Too Much Data: Dumping entire objects or large API responses makes logs hard to read and slows analysis. Log only the fields relevant to the failure.
• Logging Sensitive Information: Exposing credentials, tokens, or user data in logs can create security risks, especially in shared CI environments.

Cypress Logging vs Debugging Tools

Cypress logging and Cypress debugging tools solve different problems. Logging helps you understand what happened in a test, while debugging tools help you inspect why it happened by pausing execution, reviewing state, and replaying steps.

When Logging Is Enough

Use logging (cy.log(), targeted console logs) when you need to:

• Add context around critical test steps (e.g., “Login completed”, “Order ID captured”)
• Confirm key values used in the flow (UI text, IDs, response status)
• Quickly trace where a test started deviating from expected behavior

When to Use Cypress Debugging Tools Instead

Use Cypress debugging tools when you need deeper inspection:

• Command Log + Snapshots: Inspect DOM state before/after each command to pinpoint failures.
• Time Travel: Jump between steps to see what changed across actions.
• .debug(): Inspect the current subject in DevTools without stopping the test for long.
• cy.pause(): Pause execution and step through commands interactively to investigate timing issues.

Conclusion

Effective logging is essential for understanding how Cypress tests execute and why they fail. By using Cypress command logs, cy.log(), console logs, and built-in debugging tools correctly, teams can diagnose issues faster, reduce flakiness, and maintain more reliable test suites as applications grow in complexity.

As Cypress tests move into CI pipelines and scale across multiple environments, having clear logs and actionable debugging data becomes even more important.

Platforms like BrowserStack Automate help teams run Cypress tests in parallel on real browsers and analyze failures using rich logs, screenshots, and video recordings—making it easier to debug issues and keep automation reliable at scale.

Try BrowserStack Now