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

Trace PanelWhat It Shows
ActionsEach test step with timing and result
CallArguments and return values for the action
ConsoleBrowser console output at each step
NetworkHTTP requests and responses
SourceTest code with current line highlighted
DOM SnapshotPage structure at each action
See Playwright trace documentation for more options.

Enable Traces

Configure Playwright to record traces:
// playwright.config.ts
export default defineConfig({
  use: {
    trace: 'on-first-retry',  // Capture on retries only
  }
});
Options:
ValueBehavior
'off'No traces
'on'Trace every test
'on-first-retry'Trace only on retry (recommended)
'retain-on-failure'Keep traces for failed tests
Traces add overhead. Use 'on-first-retry' to balance debugging capability with test speed.

Upload Traces

Include traces in your upload:
npx tdpw upload ./playwright-report --token="your-api-key" --upload-full-json
The --upload-full-json flag includes trace files. Without it, trace links in TestDino will not work.

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
The trace opens in a new tab with the full Playwright trace UI.

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

PatternWhat to check
Element not foundDOM snapshot at failing step
TimeoutTimeline for long gaps, network for slow responses
Assertion mismatchExpected vs actual in DOM snapshot
Race conditionAction order across runs
  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