A failure on your machine is easy: you watched it. A failure on the build server is a line in a log nobody read, on a machine that no longer exists. What you collect automatically is all you will ever have.
Playwright's reporting is unusually good, and combined with traces it usually removes the need to reproduce anything.
The HTML report is the default and the one you will use daily:
export default defineConfig({
reporter: 'html',
});
npx playwright show-report
You get every test with its result and duration, the failure message and the exact line, the error in context, and a link that opens the trace for that test. That last link is the whole point: from a red test to a step-by-step recording in one click.
Several reporters at once is what most real projects do:
reporter: [
['html'],
['junit', { outputFile: 'results.xml' }],
['list'],
],
html for people, junit for the CI dashboard, list for readable terminal output during the run.
Read the flaky count. This is the number people ignore, and it is the most useful one in the report. With retries on, a test that fails then passes is marked flaky, not failed. Your build stays green while the suite quietly rots.
Look at that number every week. A rising flaky count means the suite is losing its value even though nothing is red.
Three habits that make reports worth having.
Upload artifacts from CI. The report, the traces and the screenshots are written on the build machine and destroyed with it. Every CI system can keep them as build artifacts. Skipping that means collecting evidence and throwing it away, and I have watched a team spend a day reproducing a failure whose trace had existed.
Name tests after behaviour. A report full of entries called "works correctly" tells you nothing. Named properly, the report becomes a readable list of what your application does, which is useful to people who never open the code.
Read the failure count before opening anything. One red test is usually a bug. Forty red tests is usually the environment: the app did not start, a migration failed, the seed user was deleted. Those need different responses, and the number tells you which you have.
Remember this: HTML report for people, JUnit for the dashboard, keep the artifacts, and watch the flaky count.
Reference: Reporters.