Per-step artifacts

Qodex captures screenshots and failure evidence for UI scenario steps so teams can debug without rerunning the test blindly.

Per-step artifacts

Artifacts are the evidence Qodex captures while a UI scenario runs. They show what the browser saw, what the page logged, what network calls happened, and why a step passed or failed.

This helps teams debug failures without guessing or rerunning the same scenario repeatedly.

What Qodex captures

Qodex captures lightweight evidence on every step and heavier diagnostic evidence when something fails.

Always captured

Artifact	What it shows
step-N.png	A viewport screenshot after the step action settles.

The screenshot gives the run detail page a visual timeline, even when every step passes.

In the test run detail page, click a step screenshot to open it in a larger lightbox. This helps when the inline preview is too small to inspect form state, copy, layout, or error messages.

Captured on failure

Artifact	What it shows
step-N-dom.html	The page HTML at the moment of failure.
step-N-console.jsonl	Console logs around the failed step.
step-N-network.jsonl	Network requests and responses around the failed step.

Console and network logs are clipped to the time window around the failed step. That keeps the evidence focused on the failure instead of burying the useful signal under earlier page noise.

Optional scenario video

Artifact	What it shows
scenario-video.webm	A recording of the full browser scenario.

Video is optional because it adds overhead. It is useful when you need to share a reproduction with someone who is not looking at the Qodex run detail page.

Where artifacts live

Artifacts are stored through Qodex’s storage backend:

• Local storage in development, under data/blobs/.
• S3 storage in production, served through short-lived signed URLs.

Artifact paths are namespaced by project and test run, so evidence from different projects does not collide.

How teams use artifacts

In the run detail view, Qodex shows the step screenshot and, for failures, the DOM, console, network, and video evidence. The failed step already has the action, selector, assertion outcome, and failure reason attached.

When you ask Qodex to fix a failed scenario, those artifacts become context for the agent. It can reason from the captured facts instead of exploring the live app from scratch.

When this matters

• A UI test fails in CI and nobody has the browser open.
• A failure only happens under one role, viewport, or environment.
• The product changed and you need to know whether the test is stale or the app is broken.
• A network request failed but the UI only showed a generic message.
• You need to share a clear reproduction with engineering or support.

Related

Replay cache and self-healing

Learn why stable steps run cheaply and failures carry useful context.

Findings

See where failed runs become tracked findings.

Self-hosted storage backends

Configure local storage or S3 for artifacts.

Intent-driven UI scenarios

Understand the scenarios that produce these artifacts.

On the roadmap

Visual regression diffing will compare per-step screenshots against a stored baseline and surface meaningful image changes above a configurable threshold.