40Reporting & Observability
What you will master here
- All built-in Playwright reporters and when to use each
- HTML report, JUnit XML, blob reports, sharding merge
- Allure integration
- Custom reporters — write your own
- Metrics, dashboards, alerts
- Tying test data into engineering KPIs
40.1 Built-in reporters
| Reporter | Format | Use for |
|---|---|---|
| list | Console line-by-line | Local dev |
| line | Single updating line | CI with limited log space |
| dot | One dot per test | Very large suites, terse |
| html | Interactive HTML report | Reviewing failures, sharing |
| junit | XML | CI dashboards (Jenkins, Bamboo) |
| json | Machine-readable | Custom processing |
| github | GitHub Actions annotations | Inline PR comments |
| blob | Binary intermediate | Shard merge (multi-machine runs) |
| null | Silent | Production / programmatic use |
// playwright.config.ts
reporter: [
['list'],
['html', { open: 'never', outputFolder: 'playwright-report' }],
['junit', { outputFile: 'results/junit.xml' }],
['github'],
],
40.2 HTML report — what's inside
- Pass/fail summary, per project, per file
- Per-test page with steps, errors, attached screenshots / videos / traces
- Filtering by project / status / file
- Link directly to a trace
- Shareable — copy folder, drop into S3 / GitHub Pages
npx playwright test npx playwright show-report # opens locally
40.3 Sharding + blob merge
Each shard writes a binary blob report. Merge into one HTML at the end.
# In each shard (CI matrix job) npx playwright test --shard=1/4 --reporter=blob,line # In the final merge job npx playwright merge-reports --reporter=html ./all-blob-reports
40.4 Allure (stakeholder reports)
npm i -D allure-playwright
// playwright.config.ts
reporter: [['line'], ['allure-playwright', { detail: true, suiteTitle: false }]],
npx allure generate ./allure-results --clean -o ./allure-report npx allure open ./allure-report
Allure gives a richer "feature → story → step" hierarchy, history trends, links to JIRA / Confluence. Common in enterprise where the report is consumed by non-engineers.
40.5 Custom reporter
// reporters/my-reporter.ts
import type { Reporter, TestCase, TestResult } from '@playwright/test/reporter';
export default class MyReporter implements Reporter {
onTestEnd(test: TestCase, result: TestResult) {
if (result.status === 'failed') {
const payload = {
name: test.title, file: test.location.file, error: result.error?.message,
retry: result.retry, duration: result.duration,
};
/* fire-and-forget to your DB / dashboard */
fetch('https://internal/qa-events', { method: 'POST', body: JSON.stringify(payload) });
}
}
}
reporter: [['list'], ['./reporters/my-reporter.ts']]
40.6 KPIs to track
| Metric | What it tells you |
|---|---|
| Pass rate | Top-line health |
| Retry rate | Hidden flakiness — high = trouble |
| p50 / p95 runtime | Long tail; slowest 5% block PRs |
| Top 10 flakiest tests | Quarantine targets |
| Top 10 slowest tests | Optimisation targets |
| PR feedback latency | Dev experience |
| Cost per PR | Infra optimisation |
| Escaped defects | Quality outcome — bugs that reached prod |
40.7 Where to put the data
- Postgres for per-test records (test_run table: id, name, status, duration, retry, build, branch)
- ClickHouse / BigQuery if volume is huge (millions of runs)
- Grafana / Looker / Metabase for dashboards
- PagerDuty / Slack for alerts on KPI breaches
40.8 Alerts that earn their keep
- "Pass rate dropped below 95% on main" — page on-call
- "Retry rate > 5% over the last 24h" — open a JIRA
- "PR feedback p95 > 15 min" — investigate infra
- "A new test is failing > 50% of the time" — auto-quarantine after 24h
40.9 Observability of the platform itself
- Worker pod CPU / RAM / disk usage
- Queue depth — backlog warning
- Browser launch time trend
- S3 artifact upload latency
- Cost per worker-hour
Module 40 — Reporting Q&A
Which reporter do you use in CI?
Usually a combination:
list for console output, html for browsable artifact, junit for the CI dashboard, github for inline PR annotations. For sharded runs, blob in each shard + merge step.What's the blob reporter and why?
A binary intermediate report each shard produces. The final merge job downloads all blob artifacts and combines into one HTML report — so failures, traces and stats are unified, not scattered.
How do you share an HTML report?
Zip the
playwright-report/ folder; upload as a CI artifact. Or publish to GitHub Pages / S3 static hosting and link the URL in the PR.When would you use Allure?
When non-engineering stakeholders need to review test outcomes — auditors, BAs, PMs. Allure groups by features/stories, shows trends, attaches screenshots and history. Heavier than the built-in HTML, but better for stakeholder consumption.
How do you write a custom reporter?
Implement Playwright's
Reporter interface — methods like onTestBegin, onTestEnd, onError. Reference it in config as ['./reporters/my-reporter.ts']. Useful for piping data into an internal QA dashboard or Slack on failure.What KPIs reveal a healthy test suite?
High pass rate, low retry rate (< 2%), short p95 runtime, slowly growing rather than ballooning, low escaped-defect rate. Single metrics lie; track trends over time.
What's a "test result database" used for?
Storing every test run with metadata (name, status, duration, retry, build, branch, commit). Enables flakiness detection, slowest-test reports, week-over-week trends, and platform health dashboards.
How do you detect a regression in test runtime?
Compare a test's p50 runtime on the current week against the prior week. Alert if it grows > 30%. Catches inadvertent waits, network slowdowns, or feature changes that bloat a flow.
What's the right alert threshold for "pass rate dropped"?
Depends on your baseline. If you usually run at 99%, a drop to 95% on main is alert-worthy. Set it just below the noise floor so you're paged on real degradation, not single-test flakes.
How do you justify reporting investment to leadership?
"Reporting turns test runs into engineering signal. Without it we can't tell flakiness from real bugs, can't see which tests block PRs, and can't measure whether quality is improving. With it, PR feedback latency, retry rate, and escaped defects become tracked KPIs we can move."