Reading the build log

Every phase of a render writes a line you can read while it happens — what each phase is doing and what its messages mean.

The job page streams a line for every phase and every line the pipeline's children print. It is not a progress bar with decoration around it — it is the actual output of the browser, the compositor and the encoder, in order, and it is the first place to look when something is not what you expected.

It is also kept forever. A finished job's Build tab holds the whole log, so a demo you made last month can still be explained.

The phases

A full demo walks five working phases plus the queue:

queued → discovering → capturing → compositing → uploading → done

Phase	What is happening	What you will see
queued	Waiting for a worker	Nothing yet — see the in-flight cap below
discovering	A browser is exploring your app and a model is choosing beats	One block per beat: the element, the action, the check
capturing	The chosen plan is replayed and filmed at 60fps	Per-step lines, then the encoder's duration
compositing	Zooms, cursor, captions and narration are assembled	Percentages, then the stitch if there is finishing
uploading	The artifacts go to storage	Key names, then the video appears

Other kinds of job walk shorter lines — a re-render skips discovery entirely, an import skips almost everything. The kinds of job has the table.

Lines from discovery

Discovery narrates its own decisions, which makes a demo that went somewhere odd easy to diagnose. Beyond the per-beat blocks, three lines are worth recognising:

fingerprint recorded: … — the browser identity discovery presented, written into the plan so that capture presents the same one. Two browsers that a site can tell apart get served different pages, which breaks a video on elements the model verifiably saw.
Step attempt failed (n/3): … — a proposed beat was refused or could not be validated, and the turn is being re-asked. Three of these in a row ends discovery with whatever it has.
discovery produced 1 step(s) — no usable flow was found — the run ended before it had a demo. This one has its own diagnosis on the failed job page, with four things to try; see When a demo fails.

Lines from capture

Capture replays the plan. Most of its lines are unremarkable — a step number, a target, a duration — but four say that something was repaired, and a repair is worth reading because it is usually a sign your app has moved since the plan was written.

selector fell back to role/name on s4 (xpath stale: …) — the recorded position of an element no longer resolves, so it was found by its accessible role and name instead. The demo is fine. If you see many of these, the plan is aging and a refresh is due.
click forced through an overlay on s3 (… intercepts pointer events) — a decorative element sat over the click point. A person's click would have gone through it, so this one did too.
wait scrolled its xpath target into view on s10 (hidden until scrolled: …) — the element was in the page but below the fold of a menu; it was scrolled to and re-checked.
NOT re-clicking: the click landed … — a rescue was skipped because the element it would have clicked reports itself already open. Clicking again would have closed it.

You may also see presenting recorded fingerprint: at the top, which is capture reading back the identity discovery wrote down, and — on jobs that hit a bot challenge — a note that the run is being retried through a different exit address.

Lines from compositing and the mix

Compositing prints percentages. Two lines after it are about sound rather than picture:

A tally of how many narration takes were spoken and how many were silent. A silent take is a real thing: when no speech credential is configured, the pipeline paces the beat with silence rather than failing, and it says so rather than letting a mute video report success.
The caption and transcript files, when there are lines to write. A demo with the voiceover switched off writes none of them, and the log says how many lines the plan holds and that none is spoken.

Failure lines

A failed job's log ends with a line beginning FAILED:. Above it, the job page renders a diagnosis when it can recognise the cause — a changed element, or a run that found no flow — with the raw log folded underneath rather than replaced. A diagnosis that hid its evidence could not be checked, so the log is always still there.

Two more endings you may meet:

CANCELLED: Cancelled by <name>. — somebody pressed Cancel on the job page. The row goes to failed immediately; the container stops at its next phase boundary.
ORPHANED — the worker running this job died (a deploy, a restart, a kill), and a reconciliation pass noticed the silence and closed the row. Nothing is lost that was not already lost; make it again.

A cancelled or failed job does not count against your daily allowance. A delivered video is what an allowance is for.