What kinds of failures does this catch that UI assertions miss?

Uncaught JavaScript exceptions, error-level console messages, failed or 4xx/5xx background requests, CORS and mixed-content blocks, and broken API calls behind a screen that still renders correctly — the classic 'looks fine, saved nothing' bug.

Is the network capture full fidelity?

Yes. Each run records a complete HAR of the session at the browser level — every request and response, with status, timing, headers, and payload shape — so nothing is sampled. A test can also surface the exact body of a specific call into the run record when that detail matters.

Does all this instrumentation slow runs down?

Barely. The console and exception listeners are passive, and the HAR is written by the browser as the session runs. To keep memory flat on passing runs we only parse the HAR into structured calls when a run fails, and we cap the size we'll parse so a huge capture can't blow up the runner.

How does it tell a real error from normal console noise?

Console capture is limited to error-level messages and genuine uncaught exceptions, then deduplicated by message and page so a repeating log counts once. When the agent explores and classifies failures, a 4xx or 5xx that a negative test deliberately triggers is tagged intentional so it isn't misread as a regression; in your generated tests you assert on the requests you choose.

Won't third-party scripts and analytics make every run noisy?

Static assets are filtered out of network failures by extension, and you assert on what you choose to — typically your own API origins and the heading that proves the page worked. The deduplication and caps keep a single flaky third-party call from burying the real signal.

What happens to the captured data after the run?

Console errors and failed requests roll up into a health summary attached to the run, and on failures the network detail is used to classify the failure and route auto-healing. The same capture feeds the security audit. Credential-bearing query values and sensitive fields are redacted before anything is stored.

Console & network testing

A page can render perfectly and still be broken — a 500 in the background, an uncaught exception, a failed fetch, a CORS block. Validate.QA listens to the console and the network for the whole session and asserts on them, not just on what the DOM paints.

Mechanism: Instrumented browser context: live console + exception listeners plus full HAR network recording, folded into the run record.

The problem: A green UI hides red wiring: a background 4xx/5xx, a failed POST after an optimistic update, or a dropped retry leaves the screen looking fine while the data never saved. Uncaught JavaScript exceptions and console errors fire constantly in real apps, but nothing fails the build because no assertion ever looks at them. CORS rejections, mixed-content blocks, and broken third-party calls only show up in the browser console — invisible to a test that just checks visible elements. When a run does fail, the actual HTTP status and response body that caused it are usually lost, so triage is guesswork instead of evidence.

Instrument the context — Every run executes in a purpose-built browser context, not a bare page. Before navigation we attach read-only listeners and force CSS animations and the Web Animations API to run instantly so the page settles deterministically — the instrumentation never changes what the app does, it only watches.

Record the console and exception stream — We subscribe to console messages and to uncaught page errors for the lifetime of the session. Error-level console output and thrown exceptions are captured with the page URL they occurred on, deduplicated by message, and capped so a noisy loop can't drown the signal.

Record the full network as a HAR — The context records a complete HAR of every request and response for the session — method, URL, status, timing, headers, and payload shape. This is full-fidelity browser-driven capture: nothing is sampled or proxied, so background fetches the UI never surfaces are all on the wire.

Surface request/response detail into the run record — An in-page capture hook lets a test emit the exact request and response body for a call it cares about, so that data lands in the structured run record — visible in the network panel — instead of being buried in a log file. Sensitive values are redacted before anything is persisted.

Assert on console and network, not just the DOM — Generated checks can require zero unexpected console errors, that key requests return the status they should, and that response payloads match. Failed responses are recorded with their status and context; during exploration and failure analysis, a 4xx that a negative test deliberately provokes is tagged intentional so it isn't misread as a regression.

Feed downstream analysis — The same capture powers more than a pass/fail. On a failed run the recorded traffic is parsed and matched against the error so failures are classified — rate limit, lost auth, server 5xx — to route healing correctly. The captured HAR also feeds the security audit, which inspects headers, cookies, tokens, and exposed data from the very same requests.

Open Console & network testing · Get Started Free