All topics·Beginner·14 / 16

Trace viewer

Before I discovered traces, I was manually adding page.screenshot() calls everywhere to debug failures. Now I just open the trace — it records every action, network request, console error, and a DOM snapshot you can interact with. Time travel through your test.

Enable tracing in config

Add trace: 'on-first-retry' to the use section of your config. This records a trace only when a test fails and is retried — so you get the trace exactly when you need it, and don't waste disk space on passing tests.

To force a trace locally for debugging, run with --trace on.

ts

// playwright.config.ts
export default defineConfig({
  retries: process.env.CI ? 2 : 0,

  use: {
    // 'off'            — не записувати (за замовчуванням)
    // 'on'             — записувати завжди
    // 'on-first-retry' — тільки при першому повторі падаючого тесту (рекомендовано)
    // 'retain-on-failure' — зберегти якщо впав (навіть без retry)
    trace: 'on-first-retry',
  },
})

bash

# Записати trace для всіх тестів (дебаг конкретного випадку)
npx playwright test --trace on

# Записати trace тільки для одного файлу
npx playwright test orders.spec.ts --trace on

Open the trace — two ways

After a run with traces, Playwright creates a trace.zip file in test-results/. Two ways to open it.

bash

# Спосіб 1: HTML репорт — натисни на іконку trace поруч з тестом
npx playwright show-report

# Спосіб 2: Відкрити .zip напряму
npx playwright show-trace test-results/orders-test/trace.zip

# Або через https://trace.playwright.dev/ — перетягни .zip у браузер

What's inside the trace

The trace viewer has several panels. The key ones I use for debugging:

text

Timeline (верх)
  — скролиш горизонтально; кожен скріншот = момент після дії
  — бачиш де тест завис або де щось пішло не так

Actions (ліво)
  — список всіх кроків: goto, click, fill, expect
  — падаюча перевірка підсвічена червоним
  — натисни будь-яку дію — побачиш сторінку в той момент

DOM Snapshot (центр)
  — інтерактивний знімок — можна клікати, наводити курсор
  — пікер елементів — клікни на елемент, побачиш його локатор

Network (права вкладка)
  — всі HTTP запити з timing, статусами, payload
  — одразу видно якщо API повернуло 500 або не відповів

Console (права вкладка)
  — console.log, console.error з контекстом кожного кроку
  — JavaScript помилки видні тут

My debugging workflow with traces

When a test fails in CI and I can't reproduce it locally, the trace is the only window into what actually happened. Here's how I read it:

text

1. Відкриваю HTML-репорт → натискаю trace-іконку поруч з падаючим тестом

2. Дивлюся на Actions — знаходжу рядок підсвічений червоним
   (зазвичай expect() яка не виконалася або click() який завис)

3. Натискаю на дію ПЕРЕД падінням — дивлюся DOM Snapshot
   Питання: "Що сторінка показувала прямо перед тим?"

4. Вкладка Network — чи прийшов API-запит? Який статус?
   Якщо 401 — проблема з авторизацією; якщо 500 — проблема сервера

5. Вкладка Console — JS-помилки які не видно у тесті

6. Якщо все виглядає правильно — перевіряю Timeline
   Чи не було race condition? Чи не завантажилась сторінка занадто повільно?

Take the quiz