Reporters
My CI config always uses two reporters simultaneously: 'dot' for terminal output (quiet, one char per test) and 'blob' when sharding for later merging. Locally I use 'html' so failures open automatically in the browser with traces attached. The 'github' reporter adds inline annotations to PR diffs — worth adding if the team reviews failures directly in GitHub.
Which reporter to use and when
The default is list locally and dot on CI. I usually override CI to use dot explicitly to avoid the verbose list output. You can combine reporters — the config takes an array, so I get terminal output AND a file simultaneously.
Terminal reporters — list, line, dot
list — one line per test, shows time. Good for local runs with <100 tests. line — one line for the last running test, updates in place. Good for large suites where you just want to see progress. dot — one character per test. · = pass, F = fail, × = fail+retry pending, ± = flaky (passed after retry). I use dot on CI to keep logs readable.
HTML reporter — the one I use for debugging
The HTML report is a self-contained web page with all test results, traces, screenshots, and videos. By default it opens automatically when tests fail. I set open: 'never' on CI (no browser to open) and open: 'on-failure' locally.
To view the last report: npx playwright show-report. To view a downloaded CI artifact zip: npx playwright show-report playwright-report.zip.
Blob reporter — for sharded CI runs
The blob reporter saves raw test data (results, traces, screenshots) to a zip file. Its entire purpose is sharding: each shard produces a blob, you download all blobs, then merge them into one HTML report. Without blob you'd have 4 separate HTML reports with no way to combine them.
CI integrations — GitHub annotations, JUnit for Azure
The github reporter adds failure annotations directly to the PR diff — clicking on a failure in the GitHub Actions summary takes you to the failing line of code. I combine it with dot so I get both annotation and terminal output.
JUnit reporter produces XML output that Azure DevOps, Jenkins, and similar tools can import into their test dashboards. I use it when the team wants to see trend data in their CI tool rather than opening the Playwright HTML report.
Custom reporters
When built-in reporters aren't enough — for example when I need to post test results to Slack or write to a custom database — I implement the Reporter interface. The key methods are onTestEnd (called after every test) and onEnd (called when the run finishes).