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

## The zip is the evidence, all of it A trace is valuable precisely because it holds everything the run saw. That is also the whole risk. Anything the Trace Viewer can display came out of the archive, so the archive contains: - **Network records** — request URLs, headers and bodies, and the responses that came back, including payloads a page never displayed. - **DOM snapshots** — the rendered page, which on a food-delivery order tracker means customer names, delivery addresses, phone numbers and order history. - **Console output** — whatever the application logged, which in practice sometimes includes identifiers and tokens developers never meant to surface. - **Test source and call parameters** — your test code, and the arguments each call received. - **Environment details** — the browser, viewport and run information recorded with the trace. None of this is unusual or a defect. It is what makes the artifact work. ## Opening is safe; sending is a transfer These two are worth separating explicitly, because teams routinely confuse them: | Action | Exposure | |---|---| | `npx playwright show-trace` on your own machine | None beyond the machine that already holds the file | | Dropping a zip on `trace.playwright.dev` | None — the page renders it locally rather than uploading it | | Emailing or posting the zip to a colleague | Full contents, to that person and to whatever archives the channel keeps | | Attaching it to a public issue tracker | Full contents, permanently, to anyone | | Serving it at a URL for `?trace=<url>` | Full contents, to anyone who can reach that URL | The hosted viewer is often the thing that gets banned, and it is the one step in that table that leaks nothing. The channel is what matters. ## A review pass before it leaves 1. **Open it yourself** and read it as the recipient will: skim the Network tab's requests and responses, and page through the snapshots around the failure. 2. **Look specifically at headers** on authenticated requests, and at any response body that carries more than the screen displayed. 3. **Ask whether the run touched real data.** A trace from a seeded environment is usually shareable as-is; one from a production-like environment usually is not. 4. **Prefer reproducing the failure against non-production data** and sharing that trace instead. It is nearly always faster than trying to sanitise an archive after the fact. 5. **Match the channel to the contents.** A trace that is fine for the team that owns the service may not be fine for a public ticket, and a zip has no permissions of its own once it is out. ## Why sanitising after the fact rarely works An archive is not a document you can redact confidently. The same value can appear in a request header, a response body, a snapshot's rendered text and a console line, and removing it from one place leaves it in three others. Repacking a trace also risks producing something the viewer will not open, at which point you have spent effort and still cannot share it. Regenerating the failure under conditions you are willing to publish is the cheaper and more honest route. ## The decision to make once, not per incident This is a policy question, not a per-failure judgement call, and it is worth settling before an outage forces it: - Which environments produce traces that may leave the team, and which do not. - Which channel a trace is allowed to travel through, and who may open one. - Whether traces served for `?trace=<url>` links sit behind authentication — remembering that such a URL must also be reachable by the viewer to load at all. - What the team does instead when a trace cannot be shared, so that the answer is a known path rather than an argument during an incident. Whether a run records a trace in the first place, and how long build artifacts are kept, are separate decisions owned elsewhere. The question here is narrower and often skipped: this archive exists and someone outside the team wants it — does it go, as is?