tamash-playwright-dashboard

A rich, self-contained HTML test dashboard reporter for Playwright. Drop it into your reporter list and every npx playwright test run appends to a single-file dashboard with pass-rate trends, per-test history across runs, step-level detail (with real locators and source locations, not just generic API labels), a dedicated Test Health view for regressions/recoveries/chronic failures/flakiness, and more — no server, no external JS/CSS, no CDN.

Live sample report

Generated from the tests in examples/tests — a real mix of passing, failing, and self-healed tests so you can see the Test Health, Self-Healing, and drill-down views populated with actual data, plus a few genuine multi-step flows against real (practice) web apps in real-world-demo.spec.js (shadow DOM, cross-frame drag-and-drop, and a full OrangeHRM add-employee/add-user flow) so the dashboard isn't only shown against contrived single-purpose fixtures. Run it yourself:

git clone https://github.com/qtpsudhakarproducts/tamash-playwright-dashboard.git
cd tamash-playwright-dashboard
npm install && npm run build
cd examples && npx playwright test

Features

• Multi-run overview — total runs, unique tests, cumulative pass rate, and a trend chart across your recorded history, with a dedicated tab for it.
• Per-run drill-down — click any run to see its own tiles and full test list, grouped by spec file with search/filter (paginated so it stays fast on suites with hundreds of tests), plus the run's actual config context (worker count, projects, shard) and a Run Integrity Warning if any tests went missing mid-run (worker crash, interruption) or a run-level error occurred outside of any test — signals Playwright reports but that would otherwise be invisible, silently looking like "a run with fewer tests."
• Per-test detail — steps with actual locators (locator('input#email')) and source file:line instead of a generic pw:api label, a custom test.step()'s subtitle shown alongside it, an expandable source-code snippet per step (so a locator.describe()'d locator's real selector is still visible), full error stack traces — including every error from expect.soft(), not just the first — the test's configured timeout budget, testInfo.annotations (issue links, skip/fail reasons) as badges, stdout/stderr, and cross-run history for that exact test (has it been flaky? when did it last fail?).
• Technical / Documentation step views — the Steps & Actions tab toggles between the raw technical step trace (with Before Hooks/After Hooks, and expect.poll()'s retry attempts, grouped into collapsed-by-default sections so they don't bury or misrepresent the real actions) and an auto-generated, plain-English "Preconditions / Steps to Reproduce / Postconditions" view (e.g. Click + getByRole('button', { name: 'Sign In' }) becomes "Click on the 'Sign In' button"), with pass/fail status on every step and a plain-English error summary inline on whichever one failed — never Playwright's raw terminal-oriented dump. Rule-based, no AI, works on runs already in history. One click copies the documentation view as plain text for a defect report or manual test-case documentation.
• Retries handled correctly, not duplicated — a test's retries collapse into the one row for that run (matching Playwright's own pass/fail/flaky verdict), with every earlier failed attempt's status, duration, error, and console output preserved in a "Retry History" section on the test detail page — not spread across several misleading extra rows inflating your pass rate.
• Failure classification — every failing test is automatically bucketed into a category (Verification Failure, Element Not Found, Action Failure, Navigation/Network Failure, Setup/Teardown Failure, Test Timeout, Test Code Error) by parsing Playwright's own error/call-log text — no configuration needed. Shown as a badge on the test detail page, filterable in the per-run test list, and rolled up on the dedicated Failure Analytics page both for the latest run and cumulatively across all recorded history (with drill-down to every occurrence — useful for backing up a defect report with real numbers, and available from your very first recorded run).
• Test Health Analytics — Newly Failed, Newly Fixed, Still Failing (with fail streaks), and Flaky, computed automatically from your run history. Summary tiles on the main dashboard link through to a dedicated, paginated analytics page with full detail and trend charts.
• Failure Analytics — a dedicated page purely about why tests are failing (as opposed to Test Health, which tracks what changed): summary tiles, the rule-based category breakdown above, plus — if you use tamash-playwright's AI failure analysis — a searchable, filterable, paginated "All Analyzed Tests" table with every AI verdict and its full explanation across all recorded runs.
• Self-Healing Analytics — if you use tamash-playwright (see below), its heal reports are read directly from the test result with zero configuration: tests/elements healed, token usage per run and cumulatively, a token usage trend, and a searchable, paginated page listing every heal event across all recorded runs. Each event's full detail is shown too — every recovery attempt tried (cache/text/vision/action-recovery, in order, with what each one found or why it failed), which fallback tiers fired, and the machine-readable failure stage — not just the final before/after selector. Invisible if you don't use it.
• AI Failure Analysis — if you're on tamash-playwright ≥ 0.13.0-beta.3 with a real AI provider configured, its verdict on a genuinely-failed test (likely-defect / likely-wrong-locator / likely-timing-or-environment / inconclusive, with an explanation) shows as a distinct badge — hover for the explanation — anywhere the rule-based failure category already appears, and the full reasoning plus attempt history appears on the test detail page's Error Diagnostics tab. Its own token cost is tracked separately from healing's, on its own tile on the Self-Healing Analytics page. Invisible if you don't use it or leave it disabled.
• Cycle & release tracking — every run is tagged with a cycle and release label (auto-defaulted by calendar day/month, or set your own via options below), shown as its own column on every table that spans multiple runs, and filterable on the main dashboard.
• Zero dependencies at report time — the generated index.html is a single static file (data inlined as JSON), safe to open directly via file:// or host anywhere.
• Metadata-only attachments — never copies screenshots/videos/traces to disk; only lists their name and type, so the dashboard folder stays small no matter how large your suite is.
• Built for large suites — every list that can grow unbounded (execution history, per-run test lists, Test Health tables, heal events, failure-category occurrences) is paginated rather than dumped on one page.

Install

npm install -D tamash-playwright-dashboard

Usage

Add it to your playwright.config.ts reporter list:

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

export default defineConfig({
  reporter: [
    ['list'],
    ['tamash-playwright-dashboard'],
  ],
});

Run your tests as usual:

npx playwright test

Each run appends to playwright-dashboard/history.json and regenerates playwright-dashboard/index.html. Locally (outside CI), the dashboard opens automatically in your default browser.

Options

reporter: [
  ['tamash-playwright-dashboard', {
    outputDir: 'playwright-dashboard',       // where to write history.json + index.html, relative to your Playwright project root
    maxHistory: 20,                          // how many past runs to keep
    autoOpen: true,                          // auto-open the dashboard in your browser after a local run
    cycleLabel: process.env.TEST_CYCLE,      // e.g. 'Sprint 42' — defaults to "<Month>-D<day>" (e.g. "September-D14") if omitted
    releaseLabel: process.env.RELEASE_NAME,  // e.g. 'v1.4.0' — defaults to the current month name (e.g. "September") if omitted
  }],
],

| Option | Type | Default | Description | |----------------|-----------|--------------------------|----------------------------------------------------------------------| | outputDir | string | 'playwright-dashboard' | Output directory, resolved against the Playwright project root. | | maxHistory | number | 20 | Maximum number of past runs kept in history.json. | | autoOpen | boolean | true | Auto-open the dashboard in the default browser after a local run (skipped when process.env.CI is set). | | cycleLabel | string | "<Month>-D<day>" | Label for whatever unit you organize test execution around (sprint, test cycle). Not inferred from CI/git — source it yourself if you want it to mean something project-specific. | | releaseLabel | string | current month name | Release/version this run was executed against, e.g. 'v1.4.0'. |

Want self-healing tests? Use TAMASH Playwright

This dashboard has no opinion on how your tests get fixed — but if you use tamash-playwright, a plug-and-play AI self-healing solution for Playwright, this dashboard automatically picks up its heal reports and surfaces them: a "Self-Heal" tab, per-test heal badges, and a full Self-Healing Analytics page with token costs and outcomes. Nothing to configure here — it just works once both packages are in your project.

npm install tamash-playwright

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

// After
import { test, expect } from 'tamash-playwright';

See the tamash-playwright README for connecting an AI provider (OpenAI, Anthropic, Gemini, Ollama, or your existing Claude/Copilot subscription).

Why not just the built-in HTML reporter?

Playwright's own HTML reporter is great for inspecting a single run in depth (traces, screenshots, videos). This reporter is complementary — it's about the trend across many runs over time: is this test newly flaky? What changed since yesterday's run? Which specs are consistently slow? That's history-shaped data the built-in reporter doesn't track across invocations.

License

Free to use, including commercially. The source code may not be copied, modified, redistributed, or resold without prior written permission. See the LICENSE file included in this package for the full terms.