PlaywrightPHP

Logs

Collect browser, console, network, and application logs without drowning failures in noise.

Logs are useful when they are targeted. They are harmful when every test emits everything.

Use logs to explain a failure: console errors, failed requests, driver startup, application diagnostics, or CI environment details.

Mental model

Collect logs near the scenario that needs them. Filter by type, URL, status, or feature.

php
$errors = [];

$page->events()->onConsole(static function ($message) use (&$errors): void {
    if ('error' === $message->type()) {
        $errors[] = $message->text();
    }
});

$page->goto('https://app.example.test/dashboard');

Assert or print the collected data after the relevant action, not inside a noisy callback.

What to log

  • console errors for the page under test;
  • failed requests for critical endpoints;
  • browser launch configuration;
  • artifact paths;
  • application correlation IDs;
  • CI runtime versions.

Choose the log source

Failure type Useful log
Page JavaScript crash console evidence and trace
API call failed request/response events or trace
Browser did not start driver and install logs
App returned the wrong screen application log and correlation ID
CI-only behavior runtime versions and environment summary

Log the source that can explain the symptom. Do not enable every channel by default.

When not to log

Do not log headers, cookies, tokens, passwords, form payloads, or full protocol messages in normal CI output.

Do not fail directly inside log callbacks unless the page is explicitly testing logging behavior. Collect the evidence, then assert after the action so the failure message remains readable.

Common pitfalls

  • Logging every request from every page.
  • Failing inside event handlers.
  • Printing secrets in headers or cookies.
  • Keeping logs only locally while CI failures need them.
  • Treating logs as a replacement for assertions.

Go next