Your Playwright trace is missing the request you need

The checkout test fails in CI, but its artifact folder contains screenshots and no usable network trace. A retry passes, and the trace from that attempt shows a healthy 200 response, which tells you nothing about the first failure. The application may be broken, but the immediate problem is that the failing attempt was not recorded or retained.

Why a real failure can leave an empty evidence trail

A trace is not a packet capture that exists independently of the test. Playwright has to start recording before the browser action, observe the request, finish the recording, and retain the resulting archive. A gap at any one of those points looks like “the request is missing,” but each gap has a different fix.

The most common mistake is a mismatch between the trace policy and the retry policy. With trace: 'on-first-retry', Playwright records only the first retry. It does not record the original attempt. If retries are disabled, no qualifying run occurs. If the retry passes, you get an excellent record of the passing path and no record of the failure that triggered it.

retain-on-failure has different semantics. Playwright starts a trace for every run, deletes it after a pass, and keeps it after a failure. That costs more during execution because passing tests are recorded temporarily, but it preserves the original failure even when a later retry succeeds. For a short-lived investigation, trace: 'on' removes retention ambiguity by keeping every run. It is too expensive and too revealing to leave enabled casually across a large suite.

Manual tracing introduces another failure mode. context.tracing.start() and context.tracing.stop() record browser operations and network activity, but they do not add Playwright Test assertions to the trace. A thrown exception can also skip tracing.stop() when it is not protected by cleanup logic. Playwright Test configuration is the safer choice for test-runner projects because the runner owns the recording lifecycle.

Finally, the request may never have happened. A disabled button, failed navigation, JavaScript error, or earlier assertion can stop execution before the trigger. No trace setting can manufacture a request that the page did not send. Check the action timeline before blaming network capture.

Capture the attempt that can actually explain the bug

Start with a failure-retention policy and an explicit assertion around the business request. The trace then supplies context, while the test still decides whether the product worked.

// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  outputDir: 'test-results',
  use: {
    baseURL: process.env.BASE_URL ?? 'http://127.0.0.1:3000',
    trace: 'retain-on-failure',
  },
});

The test below starts waiting before it clicks. That ordering matters. If the response is fast, registering waitForResponse after the click creates a race and can turn good network evidence into a timeout.

// tests/orders.spec.ts
import { test, expect } from '@playwright/test';

test('shows the submitted order', async ({ page }, testInfo) => {
  await page.goto('/checkout');

  const responsePromise = page.waitForResponse((response) => {
    const url = new URL(response.url());
    return url.pathname === '/api/orders' &&
      response.request().method() === 'POST';
  });

  await page.getByRole('button', { name: 'Place order' }).click();
  const response = await responsePromise;

  const summary = {
    method: response.request().method(),
    path: new URL(response.url()).pathname,
    status: response.status(),
    servedByServiceWorker: response.fromServiceWorker(),
  };

  await testInfo.attach('order-response-summary', {
    body: Buffer.from(JSON.stringify(summary, null, 2)),
    contentType: 'application/json',
  });

  expect(response.ok(), JSON.stringify(summary)).toBeTruthy();
  await expect(page.getByRole('heading', { name: 'Order confirmed' }))
    .toBeVisible();
});

This is deliberately not a dump of request headers or the response body. A status, method, path, and service-worker flag answer the first triage questions without copying authorization headers, cookies, personal data, or payment details into CI artifacts. Add a carefully redacted field only when it distinguishes competing causes.

There is a trade-off in retain-on-failure. Every attempt must be traced until its result is known, so a large suite will use more CPU and temporary disk than on-first-retry. Teams with reliable retries often keep on-first-retry as the normal policy and switch the affected project to retain-on-failure while investigating a first-attempt-only failure.

Tell capture failure from application failure

Run the smallest failing test once with tracing forced on:

npx playwright test tests/orders.spec.ts --trace on
npx playwright show-trace test-results/path-to-result/trace.zip

Use the actual archive path printed by the reporter or linked from the HTML report. Do not assume the first trace.zip found belongs to the failed attempt, especially when retries, projects, and shards write artifacts concurrently.

Then inspect the evidence in this order:

1. Confirm the attempt. Match the project, browser, test title, retry number, and failure message. A trace from retry 1 cannot explain a timeout on the initial run unless both attempts reached the same point.
2. Find the trigger action. In the Actions view, locate the click, navigation, or evaluation that should cause the request. If it is absent, move backward to the first failed action. The problem is execution flow, not network recording.
3. Open the Network view. Filter by the path, not a full URL containing volatile query values. Compare method and status. A 401, 404, or 500 is a received response, not a missing request.
4. Look for an unfinished transport. A request may be present without a response because DNS, TLS, a proxy, or the server connection failed. A page.on('requestfailed') listener can record the browser’s failure text, but the text is a symptom. Correlate it with proxy, server, or platform logs.
5. Check the final assertion. A successful API response does not prove the UI consumed it. If the response is healthy but the heading never appears, inspect the DOM snapshots and console errors around that transition.

If forcing --trace on creates a complete archive, capture works and the normal retention policy is wrong for this incident. If the archive opens but the action is absent, the test never reached the request. If the action exists and another observer, such as the application server, proves the call happened while the trace lacks it, investigate ownership of the traffic.

Check who actually owns the request

Page events cover requests associated with the page, but modern applications may add another network owner. A service worker can serve a cached response, proxy a fetch, or issue its own request. In Chromium, Playwright exposes service-worker requests through BrowserContext network events, and response.fromServiceWorker() tells you when a page response came through one.

For tests whose purpose is direct browser-to-server behavior, setting serviceWorkers: 'block' removes that layer. The cost is realism. An offline-capable application, push workflow, or cache update path must be tested with service workers allowed. Use separate projects when both contracts matter, rather than changing the setting until the failure disappears.

Also separate browser traffic from calls made through the Playwright request fixture or another HTTP client in test code. A browser trace is best at explaining page actions and browser network activity. If setup code creates an order through an API client before opening the page, attach a small sanitized record from that setup call. Do not expect a page’s Network view to tell the complete story of non-page work.

Routing can create a different kind of false confidence. A broad page.route() or browserContext.route() handler may fulfill the request locally, so the trace shows a clean response while the real backend was never contacted. Inspect the test’s routing setup and make the assertion explicit about whether it is validating UI behavior with a mock or an integrated backend path.

Keep useful evidence without creating a secret archive

Traces can contain DOM snapshots, screenshots, source snippets, URLs, and attachments. Network-focused debugging often adds headers and bodies on top. That is enough to expose session tokens, customer data, internal hostnames, or credentials if artifacts are uploaded unchanged.

Collect the smallest record that can disprove a hypothesis. Path, method, status, duration, request ownership, and a server correlation ID are usually more useful than an entire body. Strip query strings unless a particular parameter is under test. Allowlist safe headers instead of trying to blacklist every possible secret. Keep artifact access narrow and apply a retention period in CI.

HAR recording is useful when you need a transport archive or deterministic replay, but it is not a substitute for a trace. A HAR does not show which locator action ran, which assertion failed, or what the DOM looked like. It also increases the amount of network content you must protect. Add it for a specific question, then remove it when that question is answered.

The cost of redaction is reduced detail. Over-redaction can erase the tenant, feature flag, or correlation value that explains the incident. Prefer a derived summary produced by test code, as in the example, because its safe fields are obvious in review.

Know when more tracing is the wrong fix

Do not increase trace retention when the existing trace already proves the request returned 200 and the UI assertion failed. That case belongs in client-state, rendering, or application-log analysis. More copies of the same successful exchange add storage, not signal.

Avoid tracing every pass to compensate for an uncorrelated test. Give each attempt a test identity that also appears in server logs, then compare evidence from the same attempt. Timestamps alone are weak when parallel workers issue identical requests.

Do not block service workers merely to make a service-worker feature pass. You would be removing the component under test. Likewise, do not replace an integrated backend request with a route mock while investigating backend availability. Either change can make the symptom vanish without fixing the product.

Finally, a force-killed worker or terminated CI job may not flush its trace archive. When that is the suspected boundary, preserve runner output and infrastructure termination events, and reproduce with a controlled timeout. The right evidence may live outside Playwright because the process responsible for writing trace.zip never got the chance to finish.