skip to content

Trace Viewer

3 roadmaps4 questions

The tool a trace zip opens in, stepping action by action through DOM snapshots, network, console and the failing source line. This is how you answer "it only fails in CI".

on this pageshow

explore

questions

4

How do you open a Playwright trace zip to step through a failed run?

level: juniorimportance: must knowfreq 70%

answer

  1. One command, one zip file
  2. The viewer unpacks it for you
  3. A hosted variant needs no install
  4. Remote zips need permissive CORS
  5. show, not run

basics

~10 s

Run npx playwright show-trace path/to/trace.zip to open it in Playwright's Trace Viewer, or drag the same zip onto trace.playwright.dev, which renders it in the browser with nothing installed.

solid answer

~50 s

A trace is a single `.zip` written alongside a run's results, and the Trace Viewer is the app that replays it. Locally, `npx playwright show-trace test-results/order-tracker-live-status-chromium/trace.zip` opens it — you never unzip the file yourself, the viewer reads the archive. `show-trace` also accepts an HTTP URL, so a CI artifact can be opened in place as long as the host allows a cross-origin read. For a colleague with no Node or Playwright install, `trace.playwright.dev` is the same viewer hosted as a static site: drop the zip on the page, or pass `?trace=<url>`. It reads the file in your own browser rather than uploading it. Either route lands on the same screen: the action list on the left, the DOM snapshot on top with a screenshot filmstrip above it, and the Call, Log, Console, Network, Source and Attachments tabs underneath.

code

bash · 3 lines
bash
npx playwright show-trace test-results/order-tracker-live-status-chromium/trace.zip

npx playwright show-trace https://ci.example.com/artifacts/run-4821/trace.zip

go deeper

for a junior

Remember the one command, npx playwright show-trace, and that it takes the zip itself rather than an unpacked folder. Knowing trace.playwright.dev exists is the second half of the answer.

for a middle

Explain what is inside the archive that makes it replayable at all: recorded calls, DOM snapshots, console and network, bundled together. Mention that a URL works in place of a path.

for a senior

Show that you reach for the trace first when a run failed somewhere you were not watching, and that you can get it in front of a non-test engineer within a minute using the hosted viewer.

for a principal

Own the question of who can open a trace and through which channel, since the archive carries recorded requests and page content and the hosted viewer imposes no access control of its own.

## What a trace zip actually is A Playwright trace is **one `.zip` file** holding a recorded slice of a run: every Playwright API call the test made, the arguments passed to each one, the internal log each call produced, browser console messages, network requests with their headers and bodies, **DOM snapshots** captured around each action, and — when screenshots were recorded — a strip of images across the run's timeline. It is not a video, and it is not a text log. It is a bundle that only the **Trace Viewer** knows how to replay. The zip is self-contained. It does not reference your working copy, your `node_modules`, or the service under test, which is why a trace produced by a CI job opens fine on a laptop that has never checked the repository out. ## Opening it from the command line 1. Locate the zip. A run that recorded one leaves it under the results directory, typically `test-results/<test-name>-<project>/trace.zip`. Whether a run records one at all is a capture-configuration question, not a viewer one. 2. Run `npx playwright show-trace test-results/order-tracker-live-status-chromium/trace.zip`. The command starts a small local server and opens the viewer window on that trace. 3. Pass an HTTP URL instead of a path — `npx playwright show-trace https://ci.example.com/artifacts/run-4821/trace.zip` — and the viewer fetches the archive directly, which saves downloading and hunting for it in a build artifact bundle. You can also pass more than one trace path in a single command; the viewer stitches them onto one timeline, which is useful when a scenario spanned several traces. ## Opening it in a browser instead `trace.playwright.dev` is the same viewer built as a static web application. Two ways in: - **Drag and drop** the zip onto the page. - **Link to it** with `https://trace.playwright.dev/?trace=<url-to-zip>`, so a ticket or chat message carries a one-click reproduction of what the run saw. The file is read and rendered by JavaScript in your own browser; it is not shipped to a server for processing. That property matters twice over — it means a teammate needs no toolchain, and it means the site is not the thing that leaks a trace containing customer data. The person you send the zip to is. | Route | Needs | Best for | |---|---|---| | `npx playwright show-trace <path>` | A local Playwright install | Your own failures, right after a run | | `npx playwright show-trace <url>` | Playwright plus a CORS-permitting host | Poking at a CI artifact without downloading it | | `trace.playwright.dev` drag-and-drop | Only a browser | Handing a trace to someone outside the test team | | `trace.playwright.dev/?trace=<url>` | A publicly reachable zip | Linking a reproduction from a ticket | ## What you land on The layout is the same however you opened the file: - The **Actions** list on the left, one row per API call, in order, with each call's duration. - The **snapshot** pane, showing the page around the selected action, with the screenshot filmstrip above it when screenshots were captured. - The detail tabs — **Call**, **Log**, **Console**, **Network**, **Source**, **Attachments** — bound to whichever action is selected. Selecting an action drives every pane at once. That is the whole point of the tool: it is time travel over a run that has already finished, not a live session. ## Where people get stuck - **Unzipping first.** Do not. Hand the viewer the `.zip` itself; an unpacked directory is not what it expects. - **CORS on a URL.** `show-trace <url>` and `?trace=<url>` both need the host to serve the zip with permissive cross-origin headers. An artifact behind a login will not load, and the failure looks like an empty viewer. - **Opening the wrong artifact.** A results directory can hold several files from the same test; only the trace zip opens in the viewer. - **Expecting a trace that was never recorded.** If no zip exists, nothing about the viewer will conjure one — the run has to have been configured to capture it. - **Treating the viewer as a debugger.** Nothing in a trace re-executes. You are reading evidence, not stepping a live program.

  • Does dropping a trace on trace.playwright.dev send it to a server somewhere?
    No. The site is a static application that reads and renders the zip in your own browser, so the trace never leaves your machine by opening it. Sharing the zip with another person is what exposes its contents, and a trace can carry request bodies, headers and page data.
  • A colleague on the API team has no Node installed. How do they read your trace?
    Send them the zip and point them at trace.playwright.dev, where they drag it onto the page. Everything the trace holds — actions, snapshots, console, network — is inside the archive, so no repository checkout, no browsers and no Playwright install are needed.
  • What does passing several trace zips to show-trace in one command do?
    The viewer merges them onto a single timeline and shows their actions together, which is how you read a scenario whose evidence was recorded in more than one trace instead of flipping between two viewer windows.

saying these in an interview costs you the question

  • Claims the zip must be unpacked before the viewer reads it
  • Describes a trace as just a video of the run
  • Says trace.playwright.dev uploads your trace to a hosted service
  • Thinks you need the test repository checked out to read a trace
  • Opens the archive in a text editor hunting for the error message
  • Expects the viewer to re-run the failing test
open as a page

In Playwright's Trace Viewer, what do the Before, Action and After snapshots show?

level: middleimportance: must knowfreq 60%

basics

~20 s

They are three recorded DOM states around one action: the page as the call began, the moment input was delivered with the target point marked, and the page once the call returned. Comparing them shows what the action changed.

open as a page

You have only the trace zip from a Playwright run where an order-tracker test timed out in CI. Which Trace Viewer tabs do you read, and what does each settle?

level: seniorimportance: should knowfreq 48%

basics

~20 s

Start at the failing action, then let each tab answer one question: Call for the recorded arguments, Log for what the call waited on, the snapshots for what was on screen, Network and Console for why.

open as a page

What do you weigh before sharing a Playwright trace zip outside the team that produced it?

level: principalimportance: should knowfreq 36%

basics

~20 s

That the archive is evidence, not a screenshot: it carries recorded requests and responses, headers, page DOM and test source. Anything a session token, a customer address or an internal endpoint touched during the run is inside it.

open as a page