Reading the Log
The Log button in the header of an execution detail page opens a popover that shows everything the runner recorded while executing your tests. It is your first stop when something didn't work as expected — the log tells you what the runner was doing, in what order, and what the AI agents thought about it.
The Log is also where you trigger a verbose rerun for support, and where the resulting bundle is downloaded from.
Opening the Log
The Log button is in the right-hand area of the Execution Details header (article icon). It is only enabled when a test case is selected in the left panel — most of the log entries belong to a specific test, so the popover always opens scoped to one test at a time.
The popover floats above the page and is dismissed by clicking outside it. It can stay open while you click around the rest of the execution: selecting a different step in the timeline updates the log entries shown for that step.
The two tabs
Inside the popover, the entries are split into two tabs.
Test
Per-step entries for the currently selected test case. Each row shows:
- Step number — the index of the step in the test (matches the numbers in the left panel and the step timeline).
- Time — seconds since the execution started (so you can see how long each step took).
- Message — the log line. The icon on the left shows the severity.
Severity icons:
| Icon | Level | When it appears |
|---|---|---|
| ℹ️ | Info | The normal commentary the runner produces — "Found element X", "Cache hit", "Assertion passed". |
| ⚠️ | Warning | Something unusual but recoverable — multiple matching elements, a retry, a fallback model was used. |
| ❌ | Error | The step failed, or something fatal happened. |
| 🔧 | Debug | Extra-verbose internal events. Normally only present when the run was started in verbose mode. |
Execution
Entries that are not tied to a single step — queue events, preparation, finalization, cancellation, retries triggered by an external system, browser-process logs. The columns here are simply Time, Type, Message.
If a run never started (e.g. it sat in queue and was cancelled), all useful information will be on the Execution tab and the Test tab may be empty.
Toolbar
The popover has its own toolbar.
| Control | What it does |
|---|---|
| Tab switcher | Toggle between Test and Execution views. |
| Step filter (Test tab only) | Funnel icon. Opens a checklist of all steps in the test; uncheck steps to hide their log lines. Useful when one test has 30+ steps and you only care about a few. |
| Dev Console | Only visible while the execution is running. Opens or focuses the Developer Console window. |
| Copy to clipboard | Copies the currently visible log entries as a Markdown table. The format is portable: paste straight into a Confluence page, a Slack message, a GitHub issue, or a support ticket. |
| Refresh | Re-loads the log from the backend. The Log popover does not auto-refresh; if the execution is still running, use Refresh to see new entries. |
| Collect Support Information | Triggers a verbose rerun. Only visible when the tenant policy permits it. |
| Download Support Information | Visible after a verbose rerun has finished — downloads the bundle. |
Reading a log line
Logs are written for a human reader, not for machine parsing. Each line typically describes one decision or one action: which model was called, what it returned, which element was picked, whether a cache entry was used, whether a retry was triggered. There is no formal schema, but the patterns are consistent enough that after a few executions you'll know where to look.
A typical step in a healthy run might look something like:
Step 2 0.21s ℹ Resolved step description: "Click on the 'Save' button"
Step 2 0.34s ℹ Element search: 'Save button' → 3 candidates, picked highest-rated
Step 2 0.41s ℹ Cache hit (semantic match) for element 'Save button'
Step 2 0.55s ℹ Click executed
Step 2 0.62s ℹ Step PASSED
When something goes wrong, the surrounding context usually points at the cause:
Step 5 1.10s ℹ Element search: 'Order total' → 0 candidates
Step 5 1.32s ⚠ No candidates found; retrying with relaxed selector
Step 5 1.78s ℹ Element search (relaxed): 'Order total' → 4 candidates
Step 5 2.05s ⚠ Picked candidate with quality 0.42 (below comfortable threshold)
Step 5 2.31s ❌ Assertion FAILED: expected number, got empty string
Most of the time you don't need every log line — open the Log, scroll to the failing step (or use the filter to show only that step), and read the last few lines before the failure.
Copying for support
The Copy to clipboard button produces a Markdown table that looks roughly like:
| Step | Time | Severity | Message |
|------|--------|----------|----------------------------------------|
| 2 | 0.21s | INFO | Resolved step description: ... |
| 2 | 0.34s | INFO | Element search: 'Save button' → ... |
...
Pasting into a ticket or chat tool preserves the column alignment. Use this when you need to share specific log content with a colleague but don't want to capture the entire execution.
If you need the full picture (screenshots, AI communication, page HTML, …) use the support-information flow below instead — the Markdown copy only captures the log lines.
Verbose rerun
The Collect Support Information button is the recommended way to share a problem with the support team. It re-runs the test with verbose logging, capturing far more detail than a normal run produces.
When you click the button, a dialog asks which categories of extra data to capture:
- AI communication — every prompt sent to the AI and every response. The single most useful category for debugging why the AI did what it did.
- HTTP communication — every network request the browser made (request URL, method, headers, status, body). Useful when the test failure looks browser-side or backend-side rather than AI-side.
- HTML content — full HTML snapshots of the page at each step. Useful when an element wasn't found and you want to verify it was actually there.
- Memory snapshot — runtime memory state. Useful for diagnosing memory leaks or runaway resource use.
Pick the categories that match your suspected problem, confirm, and the runner starts a new execution with the chosen categories enabled. The original execution is left alone.
When the verbose rerun finishes (passed or failed — both are useful), the Download Support Information button replaces the Collect button in the toolbar. Click it to download a ZIP bundle. See Getting Help for what the bundle contains and how to share it.
Trigger the verbose rerun as soon as you can after a failure — preferably while the application under test is still in the same state that caused the bug. Long delays between original failure and verbose rerun reduce the chance of reproducing the exact same problem.
The Collect Support Information button only appears when the tenant has Detailed Service Request enabled and the administrator has granted access. If you don't see it, ask your tenant administrator to enable it under Tenant Settings.
Tips
- Read the log next to the screenshots. Many problems are easier to spot when you correlate a log line ("picked candidate with quality 0.42") with the screenshot the runner saw at that point.
- Use the step filter on long tests. A 60-step test produces a lot of log lines; the funnel icon lets you focus on the failing step plus a couple of context steps.
- Refresh while the run is in progress. The popover does not stream updates by itself — for a live tail, click Refresh every so often.
- Severity ≠ root cause. A Warning often precedes the Error that actually fails the step. Read the warning lines around a failure first.
null-valued log lines are normal. The runner records some events that have no message body (e.g. screenshot taken). They appear with just a severity icon and a time.