Playwright trace viewer won't open

You click Trace on a failing test and get nothing, a blank pane, an error about the protocol, or a complaint that the file is not a valid trace. There are five causes, and each has a recognisable symptom.

Symptom Cause
No Trace link on the failing test at all No trace was recorded
Viewer says it must be loaded over http:// or https:// Report or viewer opened from file://
"Not a valid trace" / nothing loads from a CI download You opened the artifact zip, not the trace
Error mentioning a newer Playwright version Viewer older than the trace format
Viewer hangs on a hosted report or in a private window Service worker can't register

1. No trace was recorded

This is the most common one, and it is a config default. The config that npm init playwright generates contains:

// playwright.config.ts
retries: process.env.CI ? 2 : 0,
use: {
  trace: "on-first-retry",
},

on-first-retry records a trace only on the first retry. Locally, retries is 0, so a failing test never retries and never records one. On CI it does — but only for tests that failed once.

For a one-off local run:

npx playwright test --trace on

To keep a trace for every failure without paying for passing tests:

use: {
  trace: "retain-on-failure",
},
trace mode Records Keeps
off nothing —
on every test everything
retain-on-failure every test failed tests only
on-first-retry first retry only that retry
on-all-retries every retry every retry

retain-on-failure records everything and deletes the passing ones, so it costs run time but not disk. On a large suite, on-first-retry with retries above 0 on CI is still the cheapest setup that catches flakes — just know it is the reason your local run has no trace.

2. Opened from file://

The trace viewer runs its loader in a service worker, and browsers do not register service workers for file:// pages. Double-clicking playwright-report/index.html gets you the test list (that part is inlined), but clicking a trace hits an error saying the viewer must be loaded over http:// or https://.

Serve it instead:

npx playwright show-report                 # serves ./playwright-report
npx playwright show-trace path/to/trace.zip  # opens one trace directly

Or open trace.playwright.dev and drop the zip on it. It is a static build of the same viewer; the zip is read inside your browser, not uploaded.

The same file:// restriction is why the whole report can come up empty on larger runs — see Playwright report is blank.

3. The CI double zip

GitHub Actions hands every artifact back as a zip of what you uploaded. Upload trace.zip and the download is a zip containing trace.zip. Upload playwright-report/ and the traces are the .zip files inside its data/ folder, inside the artifact zip.

Pass the outer archive to show-trace or trace.playwright.dev and it fails — it is a zip, just not a trace. Unzip the artifact first:

unzip playwright-report.zip -d report
ls report/data/*.zip            # these are the traces
npx playwright show-trace report/data/<hash>.zip

The rest of what goes wrong with artifacts is in GitHub Actions artifact HTML won't open.

4. Version skew

The trace format changes between Playwright releases. A trace recorded by a newer Playwright than the one running show-trace can fail with an error about the newer version. Run the viewer at the version that recorded it:

npx playwright@1.56.0 show-trace trace.zip   # match the CI version

trace.playwright.dev tracks the latest release, so it opens traces from older versions too — the quickest fallback when the local install is behind CI.

5. The service worker can't register

Even over HTTPS, the viewer needs a service worker, and some contexts refuse one:

  • Sandboxed iframes without allow-same-origin. The page gets an opaque origin, and an opaque origin cannot register a service worker. This is how most report hosts that run untrusted HTML work — Comma included (why).
  • Private windows and hardened profiles that disable service workers.
  • Remote URLs passed with ?trace=. trace.playwright.dev can load https://trace.playwright.dev/?trace=https://…/trace.zip, but the host must send Access-Control-Allow-Origin. A presigned S3 URL without a bucket CORS rule fails here.

The fix is to open the trace somewhere that has a normal origin: the local show-trace, or trace.playwright.dev with the file dropped in.

Where Comma fits

Comma shows the Playwright HTML report — test list, steps, errors — with scripts running, and lets reviewers comment on the failing test itself. It does not run the trace viewer: report HTML renders in a sandboxed iframe, which is the condition in cause 5. Attach the trace zips as assets so they travel with the report; the reviewer downloads the one they need and opens it in show-trace or trace.playwright.dev, then comes back to the thread with what they found.

One caution before you publish traces anywhere: a trace contains DOM snapshots, network requests and responses, cookies and typed input from the run. If the suite logs in with real credentials, the trace has them. Use test accounts, and share the report with people, not with a public link. More in Playwright trace.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a Playwright report →

Related