# Agent Browser Traces and Playwright Test Artifacts
Status: public
Confidence: medium (0.685) (verified)
Last verified: 2026-06-03
Generation: ai_structured


## TL;DR

Browser agents should treat traces, HTML reports, screenshots, videos, and workflow artifacts as primary debugging evidence for UI test failures.

## Core Explanation

A failing browser test is often hard to diagnose from a stack trace alone. A Playwright trace can preserve action steps, DOM snapshots, console output, network requests, metadata, and attachments. CI artifacts make those files available after the runner has disappeared.

Agents should first locate the failed test, retry count, trace ZIP, HTML report, screenshot, video, and CI artifact retention window. They should avoid inferring UI state from logs when a trace or screenshot is available.

## Source-Mapped Facts

- Playwright documentation says Trace Viewer helps explore recorded traces after a script has run and is useful for debugging failed CI tests. ([source](https://playwright.dev/docs/trace-viewer))
- Playwright documentation says traces on CI can be recorded on the first retry of a failed test with the trace option set to on-first-retry. ([source](https://playwright.dev/docs/trace-viewer))
- GitHub Actions documentation says workflow artifacts can store and share data produced by jobs in a workflow. ([source](https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow))

## Further Reading

- [Playwright Trace Viewer](https://playwright.dev/docs/trace-viewer)
- [GitHub Actions Workflow Artifacts](https://docs.github.com/en/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow)