Playwright HTML Report : Complete Guide to Allure, CI/CD and Custom Reporters
A Playwright HTML report turns automated test results into a browser-based report that testers can review after execution. It shows test outcomes, failures, execution details, and supported attachments.
Generating a report is only the first step. In a real automation project, teams also need to store reports, share them with developers, compare executions, and investigate failures.
Run npx playwright test –reporter=html to generate an HTML report. Run npx playwright show-report to view it. For advanced reporting, Playwright supports Allure integrations, JSON, JUnit XML, blob reports, and custom reporter implementations.
This tutorial focuses on building a reporting workflow that remains useful as an automation project grows.
What Is a Playwright HTML Report?
The Playwright HTML report is a browser-based test report generated by the built-in HTML reporter in Playwright Test.
It presents test execution information in an interactive format, making it easier to understand the outcome of an automated test suite.
Instead of reading every line of terminal output, you can open the report and inspect individual tests.
A Playwright HTML report can help you review:
- Total tests executed.
- Passed tests.
- Failed tests.
- Skipped tests.
- Test errors and stack traces.
- Test execution details.
- Available screenshots and other attachments.
- Trace files, when configured and captured.
- Results from different test projects or browsers.
The exact information available depends on the test configuration, the artifacts captured during execution, and the Playwright version.
Example
Suppose you are testing a login page with Playwright.
Your test suite contains three test cases:
- Login with valid credentials.
- Login with an incorrect password.
- Submit the login form without entering credentials.
If the second test fails, the HTML report helps you locate the failed test and inspect its error details.
If you have configured screenshots or traces, you may also be able to examine additional evidence to understand the failure.
In simple words: A Playwright HTML report helps you understand which tests passed, which failed, and what you should investigate next.
Why Is the Playwright HTML Reporter Important?
The HTML reporter is useful for individual developers, QA engineers, automation testers, and teams running large test suites.
2.1 Easy-to-understand test results
Terminal output can become difficult to inspect when a project contains hundreds of tests.
An HTML report organizes test results into a more convenient interface.
You can focus on failed tests instead of manually searching through the entire execution log.
2.2 Faster debugging
When a test fails, the report provides information about the failure.
Depending on the available output and configuration, you can inspect the error message, stack trace, attachments, screenshots, and traces.
This information helps you investigate the cause without immediately rerunning every test.
2.3 Better team communication
An HTML report is easier to review during bug investigations, code reviews, and team discussions.
For example, an automation engineer can share a CI-generated report artifact with another developer so they can investigate a failed test.
Remember that a report is only available to other people if you share it through an appropriate location or artifact system. A local report folder is not automatically a public website.
2.4 Useful for regression testing
Regression testing checks whether changes to an application have affected existing functionality.
After running a regression suite, the HTML report helps you identify the tests that failed and decide which failures require investigation.
2.5 Helpful for CI/CD pipelines
Automated tests frequently run in systems such as GitHub Actions and Jenkins.
An HTML report can be saved as a build artifact, allowing team members to inspect the results after the pipeline finishes.
For these reasons, the Playwright HTML reporter is useful in both small automation projects and larger testing workflows.
Prerequisites for Generating an HTML Report
Before generating a Playwright HTML report, make sure your environment is ready.
You need:
- Node.js installed.
- A Playwright Test project.
- The
@playwright/testpackage installed. - At least one test file.
- A terminal or command prompt.
If you have not created a Playwright project yet, follow the official installation guide:
https://playwright.dev/docs/intro
Step 1: Create a Playwright project
If you are starting a new project, run:
npm init playwright@latestFollow the prompts to create the project.
The setup process can generate a configuration file and example tests.
Step 2: Navigate to the project directory
Open your terminal in the directory containing your Playwright project.
For example:
cd playwright-projectReplace playwright-project with your actual project directory.
Step 3: Check the Playwright installation
Run:
npx playwright --versionThis command displays the installed Playwright version.
If the command fails, verify that your project dependencies are installed and that you are running the command from the correct directory.
How Does a Playwright Reporting Workflow Work?
A reporting workflow begins when automated tests execute and ends when the team has reviewed the results.
A typical workflow follows this sequence:
- Run the automated tests.
- Collect execution results and debugging attachments.
- Generate the required report formats.
- Save reports as CI artifacts when necessary.
- Review failed tests and identify causes.
- Fix the underlying issue and rerun affected tests.
A report is evidence of a particular execution. It does not guarantee that every application feature works.
Generate Your First Playwright HTML Report
Run the following command inside an existing Playwright Test project:
npx playwright test –reporter=html
Playwright runs the specified tests and produces a report containing the execution results.
Open it with:
npx playwright show-report
The default output directory is playwright-report.
To keep reporting consistent, configure it inside playwright.config.ts:
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
reporter: [
[‘list’],
[‘html’, {
outputFolder: ‘playwright-report’,
open: ‘never’
}]
]
});
The List reporter shows real-time test progress, whereas the HTML reporter generates a detailed report that can be reviewed later.
How to Read a Playwright HTML Report
Start by checking the overall test results.
Then open a failed test to examine its error message, test steps, and available attachments.
For an assertion failure, compare the expected value with the actual result.
For a timeout, investigate whether the application was slow, the expected element was missing, or the test was waiting for the wrong condition.
If tracing is enabled, use the available trace attachment to inspect the execution in more detail.
Useful practice: Investigate the first meaningful failure rather than assuming every failed test represents a separate application defect.
Configure Screenshots and Traces for Failure Investigation
Reports become more useful when they include evidence.
import { defineConfig } from ‘@playwright/test’;
export default defineConfig({
retries: process.env.CI ? 2 : 1,
use: {
screenshot: ‘only-on-failure’,
trace: ‘on-first-retry’,
video: ‘retain-on-failure’
},
reporter: [
[‘html’, { open: ‘never’ }]
]
});
This setup takes screenshots when tests fail, records traces during the first retry, and saves videos of unsuccessful test runs.
Collecting all evidence for every test can consume substantial storage. Choose settings according to your debugging requirements.
Generate HTML, JSON and JUnit Reports Together
Different tools need different report formats.
A browser-based HTML report helps testers inspect failures. JSON helps custom programs process results. The JUnit XML reporter generates test results in a format supported by many CI systems.
reporter: [
[‘html’, {
open: ‘never’
}],
[‘json’, {
outputFile: ‘reports/results.json’
}],
[‘junit’, {
outputFile: ‘reports/junit.xml’
}]
]
The test runner can generate all three formats from one execution.
This avoids running the same tests separately just to create different reports.
Add Allure Reporting to Playwright
Allure is useful when teams need structured test metadata, detailed attachments, and reporting workflows beyond a single HTML report.
Install the adapter:
npm install –save-dev allure-playwright
Configure it:
reporter: [
[‘html’, { open: ‘never’ }],
[‘allure-playwright’, {
resultsDir: ‘allure-results’
}]
]
Run the tests:
npx playwright test
Then use a compatible Allure report generator to turn the results into a viewable report.
For example, with a compatible Allure CLI installed:
npx allure generate allure-results –clean -o allure-report
npx allure open allure-report
Check the CLI requirements for the Allure version you install, because installation and command availability can differ between versions.
How to Preserve Allure Report History
Historical reporting helps teams compare executions rather than examining every run separately.
A report history is useful for investigating tests that fail repeatedly or become unstable after code changes.
The important requirement is preserving the history data between executions.
If a CI runner deletes its workspace after every job, historical information may be lost unless it is saved and restored.
For a history-enabled Allure workflow, follow the history mechanism supported by the installed Allure version.
Do not assume that installing the Allure adapter automatically creates a permanent history dashboard.
How to Merge Playwright Reports from Multiple CI Jobs
Large test suites may run across several CI workers.
Each worker executes part of the test suite and generates its own results.
Playwright’s blob reporter supports collecting results from separate shards and merging them later.
Generate blob reports:
npx playwright test –reporter=blob –shard=1/2
Run the second shard in a separate job:
npx playwright test –reporter=blob –shard=2/2
Collect the blob ZIP files from both jobs into a common directory.
Then merge them:
npx playwright merge-reports –reporter=html ./all-blob-reports
This creates a combined HTML report.
The merge command requires compatible blob report files. Preserve the required files from each shard and ensure the jobs use compatible Playwright versions and configurations.
Save Playwright Reports in GitHub Actions
CI reports should remain accessible after the test job finishes.
A GitHub Actions workflow can upload the report directory as an artifact.
– 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: 14
The upload step should run even if tests fail, because failure reports are often the most important ones.
The workflow must install project dependencies and browsers before running the tests.
Build a Custom Reporter for Your Team
A custom reporter lets a project process test events without relying entirely on a standard reporting format.
For example, you can count successful, failed, skipped, and interrupted test attempts.
import type {
Reporter,
TestCase,
TestResult
} from ‘@playwright/test/reporter’;
class SummaryReporter implements Reporter {
private counts: Record<string, number> = {};
onTestEnd(test: TestCase, result: TestResult) {
this.counts[result.status] =
(this.counts[result.status] || 0) + 1;
}
onEnd() {
console.log(‘Test attempt summary:’, this.counts);
}
}
export default SummaryReporter;
Configure it:
reporter: [
[‘html’, { open: ‘never’ }],
[‘./summary-reporter.ts’]
]
The example counts individual test attempts. A retried test may contribute more than one result.
For a final per-test summary, the reporter must account for retries and the final outcome of each test.
Common Reporting Mistakes
Mistake 1: Treating every failed attempt as a failed test. Retries can change the final outcome. Review retry information before calculating failure rates.
Mistake 2: Saving reports only on the CI runner. Temporary runners may delete their files after execution. Upload important reports as artifacts.
Mistake 3: Enabling every attachment for every test. Unnecessary screenshots, videos, and traces can increase storage requirements.
Mistake 4: Sharing reports containing secrets. Screenshots, network information, and logs may expose sensitive application data.
Mistake 5: Comparing unrelated test runs. A comparison is meaningful only when you understand which tests, browsers, environments, and application versions were involved.
Frequently Asked Questions
How do I open a Playwright HTML report?
Run npx playwright show-report after generating the report. Playwright opens the saved browser-based results.
Can Playwright generate HTML and JUnit reports together?
Yes. Configure both reporters in playwright.config.ts. They can produce separate outputs from the same test run.
How do I merge Playwright reports?
Use the blob reporter for distributed test execution, collect the blob results, and run npx playwright merge-reports with the desired output reporter.
Does Allure automatically store previous test runs?
Not necessarily. Historical reporting requires preserving the appropriate data between executions or using a reporting service that maintains history.
Can Playwright reports be stored in GitHub Actions?
Yes. Generate the reports during the workflow and upload them as build artifacts so they remain accessible after execution.
What is the best reporter for Playwright?
The built-in HTML reporter is a good choice for reviewing individual test runs. Allure is useful for richer reporting workflows, while JSON and JUnit serve integrations.
Conclusion
A useful Playwright reporting setup should make failures understandable and results accessible.
Start with the HTML reporter. Add screenshots and traces when debugging requires them. Use JSON or JUnit for integrations, blob reports for distributed execution, and Allure or custom reporters when your team has more specialized needs.
For the broader architecture behind test execution and reporting, read the Playwright Framework guide.
To explore reporting as part of a complete learning path, visit the Playwright Automation Testing Course in Hyderabad from Playwright Masters.
Playwright Masters Team
Playwright Automation Testing Experts | Industry-Focused Training & Practical Learning
Playwright Masters is a dedicated automation testing training platform focused on helping learners build practical skills in Playwright automation testing. Our training covers real-world automation concepts, framework practices, coding, debugging, API testing, cross-browser testing, CI/CD, and interview preparation to help learners develop job-ready testing skills.