Understanding Playwright Traces and Why Your Team Needs Access

When a Screenshot Is Not Enough

A Playwright test fails in CI. You check the error message: locator.click: Target closed. You look at the failure screenshot and see a loading spinner. That tells you the page was not ready, but not why. Did a network request fail? Did a redirect happen? Was there a JavaScript error? The screenshot captures a single frozen moment, but debugging requires the full story.

This is where most teams get stuck. The error message is too vague, the screenshot is too narrow, and reproducing the failure locally does not work because the timing is different in CI. You need a tool that recorded everything that happened during the test execution, not just the end state.

That tool exists. It is called a Playwright trace.

What a Playwright Trace Captures

A trace is a detailed recording of everything that happened during a test run. Playwright bundles it into a single .zip file that can be opened in the trace viewer, an interactive debugging interface.

Here is what a trace contains:

• Action timeline with every Playwright command (click, fill, goto, waitFor) and its exact duration
• DOM snapshots before and after each action, so you can see the page state at any point
• Network requests with full details: URL, method, status code, headers, request body, response body, timing
• Console output including logs, warnings, and errors from the browser
• Source code locations for each step, linking actions to your test file

Think of it as a flight recorder for your test. When something goes wrong, the trace contains everything you need to understand what happened and why.

How Traces Work in Playwright

Trace capture is built into Playwright. You enable it in your config:

// playwright.config.ts
import { defineConfig } from '@playwright/test'

export default defineConfig({
  retries: 2,
  use: {
    trace: 'on-first-retry',
  },
})

The trace: 'on-first-retry' setting is the recommended default. It captures a trace only when a test fails and Playwright retries it. This keeps the overhead low for passing tests while giving you full diagnostic data for failures.

Other options:

• 'off' disables tracing entirely
• 'on' captures a trace for every test (generates large files, adds overhead)
• 'retain-on-failure' captures for every test but only saves the file on failure

When tracing is active, Playwright writes a .zip file for each traced test into the test-results/ directory.

The Access Problem

Here is where most teams hit a wall. The trace file exists, but getting to it is painful.

In a typical CI setup (GitHub Actions, GitLab CI, etc.), traces end up as build artifacts. To view one, you need to:

1. Navigate to the CI job in your browser
2. Find the artifacts section
3. Download the trace .zip file
4. Open a terminal and run npx playwright show-trace trace.zip

Step 4 is the real blocker. It requires Playwright installed locally on the viewer's machine. For the engineer who wrote the test, that is fine. For the QA lead reviewing failures, the engineering manager checking test health, or the new team member investigating their first flaky test, it is a barrier.

The result is predictable. One or two people on the team actually look at traces. Everyone else asks them to summarize what happened, or they skip traces entirely and debug by guessing.

CI artifacts also expire. GitHub Actions defaults to 90 days, but many teams set shorter retention. If you are investigating a flaky test that has been intermittently failing for a month, the early traces that might show the pattern are already gone.

What the Trace Viewer Shows

The Playwright trace viewer is an interactive web application. When you open a trace, you see:

Action Timeline

A chronological list of every Playwright action executed during the test. Each entry shows the action type (click, fill, goto, expect), the target selector, and the duration. Click any action to see the page state at that exact moment.

DOM Snapshots

Before-and-after snapshots of the page for each action. You can inspect elements, check computed styles, and see exactly what was visible in the viewport. This is particularly valuable for debugging selector issues where an element exists in the DOM but is not visible or not clickable.

Network Tab

Every network request made during the test, with timing waterfall, status codes, headers, and full request/response bodies. This is where you find the root cause of many failures: a 500 error from an API, an unexpected redirect, a slow response that causes a timeout.

Console Tab

All browser console output: console.log, console.warn, console.error, and unhandled exceptions. JavaScript errors that happen during test execution often explain why an element did not render or why a click had no effect.

Source Tab

The test source code alongside the execution timeline. You can see which line of your test corresponds to each action in the trace, making it easy to correlate what you wrote with what happened.

How Euriqa Solves the Access Problem

Euriqa eliminates the friction between "trace exists" and "team can use it."

When you add the Euriqa reporter to your Playwright config, trace files are uploaded automatically during the test run. No additional CI configuration. No artifact download steps. No zip files to manage.

// playwright.config.ts
import { defineConfig } from '@playwright/test'

export default defineConfig({
  retries: 2,
  use: {
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'on-first-retry',
  },
  reporter: [
    [
      '@euriqa/euriqa-playwright',
      {
        apiKey: process.env.EURIQA_API_KEY,
        projectId: process.env.EURIQA_PROJECT_ID,
        uploadTraces: true,
        uploadScreenshots: true,
        uploadVideos: true,
      },
    ],
  ],
})

In the Euriqa dashboard, every failing test that has a trace shows a "View Trace" button. Click it and the Playwright trace viewer opens directly in your browser via a secure signed URL. No downloads, no local Playwright installation, no terminal commands.

The signed URL expires after one hour and is scoped to your project. Only team members with access can view it. A new URL is generated each time someone opens the trace.

What This Changes for Your Team

When traces require downloading zip files and running terminal commands, they are a last resort. When traces are one click away in a shared dashboard, they become the first thing people reach for.

The QA lead investigating a batch of failures can open traces for each one in browser tabs, compare them, and identify whether they share a root cause. The engineering manager who wants to understand a recurring flaky test can click into its history, open the trace from a recent failure, and see the network tab without asking anyone for help. A new hire can debug their first CI failure on day one without setting up local tooling.

This is not about the trace viewer being better in Euriqa. It is the same Playwright trace viewer. The difference is access. When access is frictionless, the data gets used. When there is friction, it gets ignored.

Beyond Traces: The Full Debugging Stack

Traces are the deepest debugging artifact, but not every failure needs that depth. Euriqa makes all three artifact types accessible in the same dashboard:

• Screenshots for quick visual checks. Is the page blank? Is an error modal showing? Often this is enough to identify the issue.
• Videos for understanding timing and sequences. Watch the test execute and see where the flow breaks. Useful for animation issues and complex multi-step interactions.
• Traces for deep investigation. Step through every action, inspect the DOM, read network responses, check console output.

Each level is available directly in the dashboard. Start with the screenshot. If that is not enough, watch the video. If you need the full picture, open the trace. All without leaving your browser.

Recommended Configuration

For teams using Euriqa, this is the configuration that gives you the best balance of debugging data and performance:

export default defineConfig({
  retries: 2,
  use: {
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'on-first-retry',
  },
})

trace: 'on-first-retry' captures a trace when a test fails and retries. You get full diagnostic data for failures without the overhead of tracing every passing test. Combined with retries: 2, this means every failure that is not immediately fatal produces a trace for investigation.

screenshot: 'only-on-failure' gives you a quick visual for every failure. video: 'on-first-retry' records the full execution on retry, useful for timing-sensitive failures.

All three artifact types are uploaded to Euriqa automatically. Your team gets screenshots, videos, and traces for every failure, accessible from the dashboard, with zero additional setup.

Give Your Team Access

The most powerful debugging tool is only useful if people can reach it. Playwright traces capture everything you need to understand a test failure. Euriqa makes them accessible to everyone on your team, instantly, in the browser.

Give your whole team access to traces. Start free at app.euriqa.dev.