Playwright Test Reporting Tools 2026: Complete Comparison Guide

Why Test Reporting Matters

Running automated tests is only half the job. The other half is understanding what happened, why it happened, and communicating results to the right people. Without effective reporting, your test suite becomes a black box — you know something failed, but you have no idea where to start debugging.

Playwright test reporting tools solve three critical problems for engineering teams in 2026:

• Debugging speed — A good report shows you the exact step that failed, the DOM state at that moment, the network requests in flight, and a screenshot or video of the failure. This turns a 30-minute investigation into a 2-minute fix.
• CI/CD visibility — When tests run in GitHub Actions or Jenkins, nobody is watching the terminal. Reports provide a persistent, browsable artifact that developers and QA leads can review after the pipeline finishes.
• Team communication — Managers, product owners, and stakeholders need summaries, not stack traces. The right reporting tool translates test results into dashboards, trends, and pass/fail ratios that non-technical people can understand.
• Flakiness detection — Historical reporting reveals which tests fail intermittently, how often, and under what conditions. Without trend data, flaky tests quietly erode confidence in the entire suite.
• Compliance and audit trails — Regulated industries require proof that tests were executed, when they ran, and what they verified. Structured reports (JUnit XML, JSON) feed directly into compliance tooling.

Playwright ships with six built-in reporters and supports third-party reporters through its plugin architecture. The challenge is not finding a reporter — it is choosing the right one for your team's workflow, CI/CD setup, and reporting needs.

Built-in Playwright Reporters

Playwright includes six reporters out of the box. Every one of them works without installing additional packages — just configure them in playwright.config.ts and run your tests.

List Reporter (default)

The List reporter is what you see when you run npx playwright test without specifying a reporter. It prints one line per test with a pass/fail indicator, test name, and duration. It is best for local development where you want quick feedback without generating any files.

# Uses list reporter by default
npx playwright test

# Explicit list reporter
npx playwright test --reporter=list

Output looks like this: each test gets a single line with a green checkmark or red X, the full test title, and how long it took. Simple, no files generated, no browser needed to view results.

Dot Reporter

The Dot reporter is the most compact option. Each test is represented by a single character: a dot for pass, an F for fail, a T for timeout. It is useful for large test suites (500+ tests) where you want to see overall progress without flooding the terminal.

npx playwright test --reporter=dot

Line Reporter

The Line reporter updates a single line in the terminal as tests run, showing the most recently completed test. It uses less vertical space than the List reporter, making it a good choice for CI logs where you want a running status indicator without thousands of log lines.

npx playwright test --reporter=line

JSON Reporter

The JSON reporter outputs structured test results as a JSON file. This is essential for custom tooling — parsing test results with scripts, feeding data into dashboards, generating Slack notifications, or building custom report UIs.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['json', { outputFile: 'test-results/results.json' }]],
});

The JSON output includes test names, statuses, durations, error messages, and attachment paths. You can parse it with any scripting language to build custom workflows.

JUnit XML Reporter

The JUnit reporter generates XML in the standard JUnit format. Every major CI/CD platform — Jenkins, GitLab CI, CircleCI, Azure DevOps — can parse JUnit XML natively to display test results in their dashboards.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['junit', { outputFile: 'test-results/results.xml' }]],
});

HTML Reporter

The Playwright HTML Reporter is the most powerful built-in option and the one we will cover in depth in the next section. It generates a fully interactive, searchable report with screenshots, videos, traces, and step-by-step test breakdowns.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['html', { open: 'never' }]],
});

Using Multiple Reporters

In practice, most teams use multiple reporters simultaneously. This is one of Playwright's best features — you can generate an HTML report for humans, JUnit XML for CI, and JSON for custom scripts, all in a single test run.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['html', { open: 'never' }],
    ['json', { outputFile: 'test-results/results.json' }],
    ['junit', { outputFile: 'test-results/results.xml' }],
    ['list'],
  ],
});

Playwright HTML Reporter Deep Dive

The Playwright HTML Reporter is the reporting tool most teams should start with. It generates a self-contained, interactive web page that you can browse locally or deploy as a static site for your team. No server required — it is a single directory of static files.

Setup and Configuration

The HTML Reporter requires zero installation. It ships with @playwright/test and generates reports in the playwright-report/ directory by default.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [['html', {
    open: 'never',          // 'always' | 'never' | 'on-failure'
    outputFolder: 'playwright-report',
  }]],

  // Enable screenshots and videos for rich reports
  use: {
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'on-first-retry',
  },
});

After tests run, open the report with:

npx playwright show-report

Filtering and Search

The HTML report provides a powerful filtering interface. You can filter tests by:

• Status — Show only failed, passed, skipped, or flaky tests
• Project — Filter by browser (Chromium, Firefox, WebKit) or device configuration
• Text search — Search across test names, file paths, and error messages
• Tags — Filter by @tag annotations if you use Playwright's tagging feature

For large test suites with hundreds of tests, the search functionality is essential. You can quickly find a specific failing test without scrolling through the entire report.

Screenshots, Videos, and Attachments

When you configure screenshot: 'only-on-failure' and video: 'retain-on-failure', the HTML report embeds these directly. Clicking on a failed test shows the screenshot at the moment of failure and a video recording of the entire test execution. For teams running visual regression testing, the HTML report also displays screenshot comparison diffs inline. This is often enough to identify the root cause without running the test locally.

Trace Attachments in HTML Reports

When traces are enabled (trace: 'on-first-retry'), the HTML report includes a "Traces" tab for each test. Clicking it opens the Trace Viewer directly in your browser — no extra tools needed. This makes the HTML Reporter + Trace Viewer combination extremely powerful for debugging CI failures.

Playwright Trace Viewer

The Playwright Trace Viewer is not a reporter in the traditional sense — it is a debugging tool that records everything the browser does during a test and lets you replay it step by step. Think of it as a time-traveling debugger for your tests.

Enabling Traces

Traces are configured in playwright.config.ts under the use section. The recommended setting for CI is 'on-first-retry', which only records traces when a test fails and is retried — minimizing storage overhead while capturing failures.

import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: 2, // Retry failed tests — trace captures the retry
  use: {
    trace: 'on-first-retry', // 'on' | 'off' | 'on-first-retry' | 'retain-on-failure'
  },
});

Other trace options:

• 'on' — Record traces for every test (high storage cost, useful during development)
• 'off' — Never record traces
• 'on-first-retry' — Record only when a test is being retried after a failure (recommended for CI)
• 'retain-on-failure' — Record all traces but only keep them if the test fails

Viewing Traces

After a test fails and a trace is generated, you can view it in three ways:

# Open a trace file directly
npx playwright show-trace test-results/my-test/trace.zip

# View trace from the HTML report (click "Traces" tab)
npx playwright show-report

# View trace online at trace.playwright.dev
# Just drag and drop the trace.zip file

What the Trace Viewer Shows

The Trace Viewer provides a timeline of every action your test performed, with the following information at each step:

• DOM snapshot — The complete DOM state at that moment, fully inspectable
• Screenshot — A visual screenshot of the page before and after the action
• Network requests — Every HTTP request/response with headers, body, and timing
• Console logs — All console.log, console.error, and console.warn messages
• Action details — The locator used, the action performed, and how long it took
• Source code — The exact line of test code that triggered each action

Timeline View

The timeline view at the top of the Trace Viewer shows a horizontal bar representing the full test duration. Each action is a segment on the timeline. You can click any segment to jump directly to that step, or drag to scrub through the test execution like a video timeline. Hovering over a segment shows the action name and duration.

This is particularly useful for diagnosing slow tests — you can immediately see which actions take the most time and whether there are unexpected delays between steps.

Allure Report Integration

The Playwright Allure Report is the most popular third-party reporter for Playwright. Allure is an open-source reporting framework originally built for Java test frameworks, now widely used across the testing ecosystem. It provides dashboards, historical trends, categorized failures, and detailed step-by-step breakdowns that go beyond what the built-in HTML Reporter offers.

Setup with allure-playwright

Installing Allure with Playwright requires the allure-playwright adapter package and the Allure CLI for generating reports.

# Install the Playwright adapter
npm install -D allure-playwright

# Install Allure CLI (via npm or Homebrew)
npm install -D allure-commandline
# or: brew install allure

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['allure-playwright', {
      resultsDir: 'allure-results',
      detail: true,
      suiteTitle: true,
    }],
    ['list'], // Keep terminal output alongside Allure
  ],
});

After running tests, generate and open the Allure report:

# Run tests
npx playwright test

# Generate Allure report from results
npx allure generate allure-results --clean -o allure-report

# Open the report in your browser
npx allure open allure-report

Allure Dashboard and Features

Allure provides several views that the built-in HTML Reporter does not:

• Overview dashboard — A high-level summary with pass/fail pie chart, severity distribution, and test duration breakdown
• Suites view — Tests grouped by file, describe block, or custom suite hierarchy
• Graphs — Duration trends, status distribution, and timeline views
• Categories — Group failures by type (product defects, test defects, known issues) to separate real bugs from test infrastructure problems
• Severity levels — Tag tests as blocker, critical, normal, minor, or trivial, and filter reports accordingly
• Steps and attachments — Allure supports step-by-step breakdowns with screenshots, logs, and custom attachments at each step

Adding Allure Metadata to Tests

You can enrich Allure reports with metadata directly in your test files:

import { test, expect } from '@playwright/test';
import { allure } from 'allure-playwright';

test('checkout flow completes successfully', async ({ page }) => {
  allure.severity('critical');
  allure.feature('Checkout');
  allure.story('Complete purchase');

  await allure.step('Navigate to product page', async () => {
    await page.goto('https://shop.example.com/product/1');
  });

  await allure.step('Add to cart', async () => {
    await page.getByRole('button', { name: 'Add to Cart' }).click();
  });

  await allure.step('Complete checkout', async () => {
    await page.getByRole('button', { name: 'Checkout' }).click();
    await expect(page).toHaveURL(/confirmation/);
  });
});

History Trends

Allure's most valuable feature for mature teams is history trending. By preserving the allure-results/history directory across CI runs, Allure tracks pass/fail rates over time, shows which tests have become flaky recently, and identifies regressions. This requires copying the history folder from the previous report into the current results directory before generating the new report.

# In CI: copy history from previous report before generating new one
cp -r allure-report/history allure-results/history 2>/dev/null || true
npx allure generate allure-results --clean -o allure-report

Third-Party Reporters

Beyond Allure, several third-party platforms provide hosted reporting for Playwright. These are best for enterprise teams that need real-time dashboards, team-wide visibility, and analytics that go beyond what static HTML reports offer.

ReportPortal

ReportPortal is an open-source (with enterprise tier) test reporting platform that provides real-time dashboards, AI-powered failure analysis, and cross-project reporting. It runs as a self-hosted service and integrates with Playwright via the @reportportal/agent-js-playwright package.

npm install -D @reportportal/agent-js-playwright

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['@reportportal/agent-js-playwright', {
      apiKey: process.env.RP_API_KEY,
      endpoint: 'https://reportportal.yourcompany.com/api/v1',
      project: 'web-automation',
      launch: 'Playwright Regression',
      attributes: [
        { key: 'browser', value: 'chromium' },
        { key: 'env', value: 'staging' },
      ],
    }],
  ],
});

Key ReportPortal features: real-time test execution monitoring, AI-assisted failure triage, defect type classification, cross-launch comparison, and role-based dashboards for QA leads, developers, and managers.

Currents

Currents is a cloud-hosted test reporting platform designed specifically for Playwright and Cypress. It provides real-time results streaming, parallel execution orchestration, flakiness detection, and GitHub/GitLab/Slack integrations out of the box.

npm install -D @currents/playwright

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['@currents/playwright', {
      projectId: 'your-project-id',
      isCI: !!process.env.CI,
    }],
  ],
});

Currents is a paid service with a free tier. Its main advantage over self-hosted solutions is zero infrastructure management — results stream to their cloud in real time, and you get dashboards, Slack alerts, and GitHub commit status checks immediately.

Tesults

Tesults is another cloud-based reporting platform that supports Playwright via its Node.js library. It focuses on team collaboration — test results are organized by target (browser, environment), and team members can be assigned to investigate specific failures.

npm install -D tesults

Tesults requires implementing a custom reporter that pushes results to their API. It is less plug-and-play than Currents or ReportPortal but offers flexible data modeling for teams with complex test environments.

Custom Reporters

Playwright's reporter API is extensible. You can build a fully custom reporter by implementing the Reporter interface. This is useful for teams that need to push results to internal dashboards, trigger specific workflows, or format data for non-standard tools.

import type { Reporter, TestCase, TestResult, FullResult } from '@playwright/test/reporter';

class SlackReporter implements Reporter {
  private passed = 0;
  private failed = 0;

  onTestEnd(test: TestCase, result: TestResult) {
    if (result.status === 'passed') this.passed++;
    if (result.status === 'failed') this.failed++;
  }

  async onEnd(result: FullResult) {
    const message = `Tests: ${this.passed} passed, ${this.failed} failed`;
    await fetch(process.env.SLACK_WEBHOOK!, {
      method: 'POST',
      body: JSON.stringify({ text: message }),
    });
  }
}

export default SlackReporter;

// playwright.config.ts — using a custom reporter
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['html'],
    ['./reporters/slack-reporter.ts'],
  ],
});

Reporter Comparison Table

Here is a side-by-side comparison of every major Playwright test reporting tool available in 2026. Use this table to choose the right reporter based on your team's needs.

Best Practices for Playwright Test Reporting

Choosing the right reporter is only the first step. These best practices ensure your Playwright test results are useful, accessible, and actionable in a production CI/CD pipeline.

1. Always use multiple reporters in CI

In CI/CD, combine reporters for different audiences. The HTML report serves developers debugging failures, JUnit XML feeds the CI dashboard, and JSON enables custom tooling like Slack notifications.

// Recommended CI reporter configuration
import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    ['html', { open: 'never' }],             // Interactive report for devs
    ['junit', { outputFile: 'results.xml' }],  // CI dashboard integration
    ['json', { outputFile: 'results.json' }],  // Custom tooling / Slack
    ['dot'],                                  // Compact CI log output
  ],
});

2. Upload reports as CI artifacts

In GitHub Actions, upload the playwright-report/ and test-results/ directories as artifacts so team members can download and view them after the pipeline completes.

# .github/workflows/tests.yml
- name: Run Playwright tests
  run: npx playwright test

- name: Upload HTML report
  if: ${{ always() }}
  uses: actions/upload-artifact@v4
  with:
    name: playwright-report
    path: playwright-report/
    retention-days: 30

- name: Upload test results (traces, screenshots)
  if: ${{ always() }}
  uses: actions/upload-artifact@v4
  with:
    name: test-results
    path: test-results/
    retention-days: 14

3. Deploy reports to a static hosting service

For team-wide access without downloading artifacts, deploy HTML reports to GitHub Pages, S3, Netlify, or Vercel. This gives every team member a URL they can bookmark and share in Slack or Jira tickets.

# Deploy to GitHub Pages after tests complete
- name: Deploy report to GitHub Pages
  if: ${{ always() }}
  uses: peaceiris/actions-gh-pages@v3
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    publish_dir: playwright-report/
    destination_dir: reports/${{ github.run_number }}

4. Send Slack notifications with test summaries

Use the JSON reporter output to send automated Slack messages after each CI run. Include the pass/fail count, duration, and a link to the full HTML report.

#!/bin/bash
# Parse JSON results and send to Slack
PASSED=$(jq '[.suites[].specs[].tests[] | select(.status == "expected")] | length' results.json)
FAILED=$(jq '[.suites[].specs[].tests[] | select(.status == "unexpected")] | length' results.json)

curl -X POST "$SLACK_WEBHOOK" \
  -H 'Content-Type: application/json' \
  -d "{\"text\": \"Playwright: $PASSED passed, $FAILED failed. <$REPORT_URL|View Report>\"}"

5. Configure trace retention strategically

Traces are large files (10-50 MB each). Use trace: 'on-first-retry' in CI to only capture traces for failing tests. Set artifact retention to 14-30 days to avoid ballooning storage costs. For critical test suites, keep traces for 90 days for regression analysis.

6. Tag tests for filtered reporting

Use Playwright's @tag annotations to categorize tests. This lets you filter reports by feature, priority, or team, making large reports navigable.

test('checkout completes @critical @checkout', async ({ page }) => {
  // This test will be filterable by @critical and @checkout tags
  await page.goto('https://shop.example.com');
  // ...
});

// Run only critical tests and generate a focused report
// npx playwright test --grep @critical

7. Monitor report size in CI

HTML reports with screenshots and videos can grow to hundreds of megabytes. Monitor artifact sizes and set budgets. If reports exceed your target size, switch to screenshot: 'only-on-failure' and video: 'retain-on-failure' to reduce output.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn