Skip to main content

Developer Console & Network Inspection

The Developer Console is a pop-out tool window that sits next to a running execution and gives you direct, AI-assisted access to the browser the runner is driving. It is the right place to be when you are debugging an interactive recording session, exploring a page you've never tested before, or building a difficult selector.

For finished executions, there is a separate Timing analysis dialog that lets you inspect network traffic and wait events of the run. Both tools are covered on this page.

Opening the Developer Console​

The Developer Console is only available while a test execution is in progress. There are two ways to open it:

  • From the Log popover toolbar — the Dev Console icon (only visible while the execution is running). See Reading the Log.
  • From the browser frame in the execution detail view — the Dev Console button in the simulated browser's toolbar.

The console opens in a separate browser window so it doesn't compete for space with the execution view. Closing the console window does not affect the running execution.

If a console window is already open for the execution, clicking the icon focuses it instead of opening a second one.

The three tabs​

The console window has three tabs. They are independent — you can leave the AI Tools tab in mid-flow, switch to the DOM Inspector to check a selector, and come back without losing state.

AI Tools​

The AI Tools tab is a pair of mini-prompts you can fire against the live page.

  • Element finder. Describe an element in plain language (e.g. "the Save button in the top-right corner of the dialog") and the AI returns a candidate XPath plus a highlighted screenshot showing what it picked. Use this to verify that your description is unambiguous before committing it as a step.
  • Assertion tester. Write an Expect-style sentence (e.g. "the cart contains exactly 3 line items") and the AI evaluates it against the current screenshot, returning Pass / Fail with an explanation. Use this to validate an assertion's wording before recording it as a step.

Both flows are read-only — they do not change the test or the page.

tip

The AI Tools tab is the fastest way to iterate on prompt wording during recording. If the element finder picks the wrong element with your description, rewrite the description until it picks the right one, then commit that wording to a recorded step.

DOM Inspector​

A live, navigable view of the DOM of the page the runner is currently on.

Features:

  • Tree view. The DOM tree, with expandable nodes, attributes, and text content.
  • Frame selector. A dropdown listing each iframe / shadow-DOM root on the page; pick one to inspect inside it. The main frame is the default.
  • Search. Find by tag name, attribute or text content.
  • Click-to-locate. Click any point in the screenshot of the execution view and the matching DOM node is highlighted in the inspector. The reverse also works: clicking a node in the inspector highlights it in the screenshot.
  • Copy. Copy XPath / outer HTML / attributes of the selected node.

The inspector is read-only — you cannot edit the DOM through it. To execute changes against the page, use the Console tab.

Console​

A standard JavaScript console attached to the page. Type any expression and see the result. Common uses:

  • Inspect application state — e.g. read a Redux store, a Vue / Angular component, or a window-level variable.
  • Trigger one-off helpers — e.g. clear a sticky cookie or reset a hidden flag during a recording session.
  • Verify the value of a parameter the test will later read from the page.

Anything you do here happens to the real browser the runner is using. If you mutate state, the next step that the runner executes will see your changes.

When to open the Developer Console​

The console is most useful in these situations:

  • You're recording a new test and the AI element finder keeps picking the wrong element. Use the AI Tools tab to rephrase until the finder picks the right one, then commit that wording.
  • You're chasing a "no candidates found" failure during recording. Use the DOM Inspector to verify the element actually exists, what its attributes are, and which frame it lives in.
  • You need to verify an assertion's wording. Use the AI Tools assertion tester before committing the step.
  • You need to set up the page in a way that's awkward through the UI — e.g. clear a banner, set a feature flag, force a date in the application. Use the Console tab while the browser is unlocked.

The console is not useful for finished executions — at that point the browser is gone, only the recording remains. For finished runs use the Timing analysis dialog (next section).

Timing analysis (finished runs)​

For runs that have completed (Passed or Failed), the Timing analysis dialog lets you inspect what happened on the network during execution.

Open it from the ⓘ Info popover of a test in the left panel (chart icon, visible only for terminal runs).

The dialog has two tabs:

Summary​

High-level totals for the run: how many network requests, how many failed, how much time was spent waiting on the network vs. waiting on the UI, fastest / slowest requests, and which steps had the highest network cost. Useful to spot e.g. a single slow API call dominating the test runtime.

Details​

A filterable timeline of every captured event:

  • Network requests — URL, HTTP method, status code, duration, resource type (XHR, fetch, document, script, image, …), and failure reason if any.
  • Wait events — the auto-waiting decisions the runner made (which condition was waited for, how long, whether it timed out).

Filter chips at the top of the Details tab let you narrow down to:

  • A specific step — see only requests fired during that step.
  • A specific event type — only network requests, only waits.
  • A specific resource type — only XHR / fetch, only document loads, only images, …
  • Failed-only — only requests that returned an error status or never completed.
  • Timed-out-only — only wait events that hit their timeout.

The timeline view aligns requests and waits with the step that issued them, so you can answer questions like "Was Step 5 slow because of the network or because of the page rendering?" at a glance.

tip

The most useful filter is Failed-only when a step succeeded according to the AI but the screen looked broken. A 500 on a background XHR often correlates with the user-visible bug even when the step itself passes.

Network traffic during a running execution​

Network requests during a running execution are not exposed in the Dev Console tabs directly. They are captured and become visible in the Timing analysis dialog after the execution finishes. If you need to inspect network behaviour live, use the page's own browser DevTools (open via your normal F12 shortcut on the embedded browser).

What the console can and cannot do​

The Developer Console is a debugging aide, not a way to permanently change a test. Anything you do in the console is local to one running browser instance:

  • ✅ See what the runner sees — same DOM, same state.
  • ✅ Drive the page manually (Console tab — JavaScript) while the browser is unlocked.
  • ✅ Search for elements with the AI Tools tab and rehearse descriptions.
  • ❌ Change the test definition. Use the Recording UI or the Steps tab for that.
  • ❌ Replay assertions against historical screenshots. The AI Tools tester runs against the current live screenshot.
  • ❌ See network traffic in real time. Use Timing analysis after the run, or the browser's native DevTools live.

See also​

  • Reading the Log — the runner's own log; opens the Dev Console from its toolbar.
  • Recording — the interactive recording flow that the Dev Console pairs with.
  • Auto-waiting — what the wait events in Timing analysis represent.
  • Failed-execution triage — when network failures correlate with test failures.