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 loadhttps://trace.playwright.dev/?trace=https://…/trace.zip, but the host must sendAccess-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.