Skip to main content
Playwright traces capture every action, network request, and DOM state during test execution. TestDino displays these traces so you can debug failures without re-running tests locally.

​
Quick Reference

The Trace Viewer has several panels, each displaying different execution details. Use this table to find the appropriate panel for your investigation. See Playwright trace documentation for more options.

​
Enable Traces

Configure Playwright to record traces:
Options: Traces add overhead. Use 'on-first-retry' to balance debugging capability with test speed.

​
Stream Traces

Traces stream to TestDino during the run once @testdino/playwright is configured. Any trace Playwright records for a test, based on your trace setting above, reaches the dashboard with no separate upload step.
@testdino/playwright streams screenshots, videos, and traces by default. Pass --no-artifacts to npx tdpw test to skip them. Without a recorded trace, trace links in TestDino will not resolve, so keep trace set to 'on-first-retry' or stronger.

​
When to Use Traces

Traces are most useful for:
  • Race conditions: See if an element appeared after the test tried to interact
  • Timing issues: Check how long each step took
  • Network failures: Inspect API requests and responses
  • Complex flows: Step through multi-page interactions
For simple failures, start with screenshots or error messages. Open traces when you need more detail.

​
Open the Trace Viewer

1

Open a test run

Navigate to the test run in TestDino
2

Click a failed test

Select the test you want to debug
3

Select the attempt tab

Choose Run, Retry 1, or Retry 2
4

Open the trace

Click View Trace or the trace viewer link
Playwright Trace Viewer showing timeline, actions, network, and DOM panels
TipThe trace opens in a new tab with the full Playwright trace UI.

​
Use a Custom Trace Viewer

Point a project at your own trace viewer to open traces somewhere other than the default https://trace.playwright.dev. Every trace link in the project then opens in your viewer. This is available on Enterprise plans. Set the URL under Project Settings → General → Trace Viewer. A custom viewer must accept the same ?trace= parameter as the default viewer, such as a self-hosted Playwright fork that adds extra panels.
NoteThe custom viewer changes where the trace opens. Trace recording and upload are unchanged.

​
Actions Panel

The left sidebar lists every action in execution order:
  • page.goto
  • locator.click
  • expect.toBeVisible
Click any action to see its details. Failed actions are highlighted in red.

​
Timeline

The timeline at the top shows action duration. Long bars indicate slow steps. Gaps may indicate waiting or idle time.

​
DOM Snapshot

Each action captures a DOM snapshot. Use it to see:
  • Whether the element existed
  • What the page looked like at that moment
  • If other elements were blocking the target
Toggle between Before and After to see DOM changes from the action.

​
Network Tab

View all HTTP requests during the test:
  • Request URL, method, and headers
  • Response status, headers, and body
  • Timing breakdown (DNS, connect, SSL, wait, download)
Failed requests appear in red. Look for 4xx/5xx responses or timeouts.

​
Console Tab

Shows browser console output at each action:
  • console.log from application code
  • JavaScript errors and warnings
  • Failed resource loads
Console errors often reveal issues not visible in the UI.

​
Source Tab

Displays the test code with the current action highlighted. Useful for correlating trace steps with your test file.

​
Debug Common Failures

  1. Go to the failed action
  2. Check the DOM snapshot
  3. Look for the target element
If the element exists but the locator did not match, the selector is wrong. If the element does not exist, the page state was different than expected.
  1. Check the action duration in the timeline
  2. Look at the DOM snapshot before timeout
  3. Check the network tab for pending requests
Timeouts often mean the page was still loading or an element was not yet visible.
  1. Go to the failed expect action
  2. Check the Call panel for expected vs actual values
  3. Review the DOM snapshot to see the actual state
  1. Compare DOM snapshots before and after the action
  2. Check if elements appeared or disappeared between steps
  3. Look at network timing to see if responses arrived late

Visual Evidence

Screenshots and videos

Error Grouping

Find patterns across failures

Flaky Tests

Identify and manage flaky tests

Node.js CLI

CLI setup and options