A console error is not an uncaught exception.

A test reaches its final assertion and passes. During the action, the page logs an error message. In another run, a script throws an uncaught exception while the interface still displays the expected heading. Both events deserve investigation, but they are different signals. A listener that collects only one cannot describe the other reliably.

Playwright's Page API documents console events for calls to the page's console API and pageerror events for uncaught exceptions. ConsoleMessage exposes a message type and text. Keep the event channel in the evidence record so an error-level log does not become an invented exception diagnosis.

Attach the listener before the action

Our invented page has one button that calls console.error and another that schedules a thrown Error. It contains no external resources or customer data. The local test listens before clicking and checks the resulting event through its own channel.

const pending = page.waitForEvent('console', message =>
  message.type() === 'error' && message.text() === 'demo diagnostic'
);
await page.getByRole('button', { name: 'Log demo error' }).click();
const message = await pending;
expect(message.text()).toBe('demo diagnostic');

This snippet needs the Playwright runner, imported expect and the local button fixture. The wait starts before the click to capture a fast event. It matches an invented exact message, not every console error in a real application. Register a separate pageerror listener for uncaught exceptions.

The local demonstration confirms that the controlled console.error call generates the selected console event without adding a pageerror. A separate scheduled throw generates a pageerror with the controlled message. These checks establish this fixture's event behavior; they do not classify every browser diagnostic or library logging policy.

Keep collection separate from the release rule

Receiving an event does not, by itself, create a failed test assertion. Write the policy explicitly: which unexpected events fail this journey, which known diagnostics are allowed and who owns each exception. Keep allowlists narrow and reviewable rather than silencing the entire error channel.

Inspect message origin and the surrounding action before assigning a cause. A console statement can report a handled condition. An uncaught exception can occur in work unrelated to the currently visible heading. Neither event alone proves whether the required record was saved, so retain the journey's outcome assertions.

If setup or navigation happens before listeners are attached, the collected list is incomplete for that period. State the observation window in the report. Do not call an empty list a clean application when the test did not observe startup or another relevant page.

Protect diagnostic artifacts

Console arguments and error text may contain record details, tokens or URLs. Collect only what the case needs and redact before sharing. Do not serialize every argument into public artifacts just because the API permits reading it. Our example uses fixed invented strings only.

When a generated test adds diagnostic listeners, review listener timing, message filtering and the assertion that consumes the result. AnyTest describes app exploration and end-to-end tests for human review. No specific AnyTest console-monitoring feature is claimed here. A useful failure report names the observed channel, relevant action, expected outcome and the evidence that remains missing.

A listener on one page does not establish what happened in a separately opened page. Keep evidence associated with the page and observation window it came from. Investigate missing coverage before combining separate diagnostic lists into a release conclusion.