Debugging Playwright failures in CI is harder than it should be

Source: Dev.to

Problem

Running Playwright tests locally makes debugging failures straightforward: you run the test, open the trace viewer, inspect the DOM, and quickly identify the issue.
When Playwright runs inside CI, the process becomes much messier.

Typical failure workflow

1. A test fails in GitHub Actions / GitLab CI.
2. You open the job logs.
3. You download the artifacts.
4. You unzip the HTML report.
5. You open the trace locally.
6. If the suite runs in parallel, you repeat the steps for other jobs.

At this point, debugging the test can take longer than fixing the issue. As the suite grows—especially when tests run across 10–20 CI jobs or shards—understanding what actually happened requires digging through traces, logs, and screenshots spread across multiple artifacts.

Why CI debugging is hard

• The slow part isn’t root‑cause analysis; it’s reconstructing the failure context.
• Scattered artifacts must be downloaded and examined locally.

Making CI debugging easier

• Enable tracing with trace: "on-first-retry" or trace: "retain-on-failure".
  These settings are essential but still leave you with dispersed artifacts.

Instead of downloading each artifact, you can reconstruct the entire CI run into a single debugging view. This unified view lets you open a failed test and immediately inspect:

• Trace
• Screenshots
• Logs
• Video
• CI metadata

All without downloading anything.

Demo

A simple demonstration of this approach is available at:

https://sentinelqa.com/demo

---

Curious how other teams debug Playwright failures in CI once their test suites start running across multiple jobs.