Debugging Playwright failures in CI is harder than it should be

If you run Playwright tests locally, debugging failures is usually straightforward.

You run the test, open the trace viewer, inspect the DOM, and quickly figure out what went wrong.

But once Playwright runs inside CI, things start to get messy.

A typical failure workflow looks like this:

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. You repeat this for other jobs if the suite runs in parallel

At this point debugging the test sometimes takes longer than fixing the issue.

The bigger the suite gets, the worse this becomes.

If tests run across 10 to 20 CI jobs (or shards), understanding what actually happened requires digging through traces, logs and screenshots across multiple artifacts.

In other words:

The slow part of Playwright debugging in CI is not root cause analysis.

It's reconstructing the failure context.

What usually helps

A few things make CI debugging easier:

• Enable trace: "on-first-retry" or trace: "retain-on-failure"
• Save screenshots/videos on failure
• Upload artifacts from CI

These are essential, but they still leave you with scattered artifacts that must be downloaded locally.

A different approach

Instead of downloading artifacts, we started reconstructing the entire CI run into a single debugging view.

This way you can open a failed test and immediately inspect:

• trace

• screenshots

• logs

• video

• CI metadata

without downloading anything.

Here is a simple demo of what that looks like:

https://sentinelqa.com/demo

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