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. Exploration reports them in the health report, and API tests assert on the responses directly.

Is the network capture full fidelity?

Yes. Each UI test run records a 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 used during exploration are passive, and the HAR is written by the browser as the run goes. 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. Generated UI tests do not assert on those findings; they stay in the health report, and API tests assert on status and response shape.

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

Static assets are filtered out of network failures by extension, and each failed request is deduplicated and capped, so a single flaky third-party call shows up once in the health report instead of burying the real signal. Generated UI tests don't assert on those failures; they assert the outcome that proves the page worked, such as its heading.

What happens to the captured data after the run?

Console errors and failed requests seen during exploration roll up into a health report on the discovery session, and when a test run fails its recorded network traffic 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.

Catch the errors users cannot see.

Surface uncaught exceptions, failed requests, and network errors during the same test run.

Mechanism: Instrumented browser context during exploration (console and exception listeners plus HAR recording), and HAR recording on every UI test run.

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, and nobody looks at them because no screen shows 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 — Exploration, test generation, and healing sessions run 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 — During exploration, test generation, and healing sessions 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 page and message, and capped so a noisy loop can't drown the signal. Ordinary test runs record network traffic but do not listen to the console.

Record the full network as a HAR — Every UI test run records a HAR of its requests and responses — method, URL, status, timing, headers, and payload shape. This is browser-driven capture: nothing is sampled or proxied, so background fetches the UI never surfaces are on the wire too.

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 API responses, not just the DOM — Generated API tests check that key requests return the status they should and that response payloads match. Generated UI tests do not assert on console errors; those go into the health report from exploration. 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