Logging in Playwright Automation

Introduction

In the world of automated testing, Logging is your most important diagnostic tool. When a test fails in a remote CI pipeline at 3:00 AM, you won't be there to see it. Your only clue to what went wrong will be the logs left behind. A well-logged test suite doesn't just say "Test Failed"; it tells a story of exactly what the browser was doing, qué happened just before the error, and what the application state was.

Playwright offers multiple layers of logging, from simple console output to full network and trace logs. In this guide, we'll explore how to build a professional logging strategy for your Playwright suite in 2026.

---

1. Simple Console Logging

The most basic form of logging is using console.log() inside your tests. While simple, it's often all you need to track basic progress.

test('Should complete purchase flow', async ({ page }) => {
  console.log('Navigating to homepage...');
  await page.goto('/');
  
  console.log('Searching for product...');
  await page.fill('#search', 'Playwright Hoodie');
  
  console.log('Clicked "Add to Cart"');
  await page.click('.add-to-cart');
});

---

2. Browser Console Logs

Sometimes the issue isn't with your test script, but with the application itself. Playwright can listen to the browser's console and capture any logs or errors generated by your site's JavaScript.

page.on('console', msg => {
  if (msg.type() === 'error') {
    console.log(`BROWSER ERROR: "${msg.text()}"`);
  }
});

---

3. Network Incident Logging

One of the most powerful features of Playwright is the ability to monitor network traffic. Logging failed API calls can help you distinguish between a UI bug and a backend failure.

page.on('requestfailed', request => {
  console.log(`REQUEST FAILED: ${request.url()} [${request.failure().errorText}]`);
});

---

4. Advanced: Custom Playwright Reporters

For large enterprise projects, standard console logs aren't enough. You need structured data. Playwright allows you to create Custom Reporters that can send logs to services like Datadog, ELK, or a custom internal dashboard.

// my-reporter.ts
import { Reporter, TestCase, TestResult } from '@playwright/test/reporter';

class MyReporter implements Reporter {
  onTestEnd(test: TestCase, result: TestResult) {
    if (result.status !== 'passed') {
      console.log(`[ALERT] Test ${test.title} failed in ${result.duration}ms`);
    }
  }
}
export default MyReporter;

---

5. The Trace Viewer: The Ultimate Log

While text logs are helpful, the Playwright Trace Viewer is the ultimate form of logging. It records every action, every network request, every console log, and every DOM change. In 2026, it is the standard "post-mortem" tool for any failed test.

// playwright.config.ts
export default defineConfig({
  use: {
    trace: 'retain-on-failure',
  },
});

---

Best Practices for Test Logging

1. Be Concise: Don't log things that are obvious. Log the intent of the action, not the action itself (e.g., "Logging in user..." instead of "Clicking button #submit").
2. Level Up: Use different log levels (INFO, WARN, ERROR) if you are using a dedicated logging library like winston or pino.
3. Include Context: When logging a failure, include metadata like the browser name, the environment (Staging/Dev), and the current URL.
4. Scrub PII: Never log sensitive user data like credit card numbers or raw passwords.

---

Conclusion

Logging is the bridge between a test failure and a bug fix. By implementing a multi-layered logging strategy—combining script logs, browser logs, and full execution traces—you ensure that your team has all the information they need to keep your application stable. In the data-driven world of 2026, a well-logged automation suite is a mark of professional engineering.

---