When a demo fails

A failed job's page leads with a diagnosis where Demofy can recognise the cause, and folds the raw build log underneath it rather than replacing it. Where it cannot recognise the cause it says nothing and leaves the log open, because a diagnosis that guessed would tell you your site changed when the truth was a container running out of memory.

This page is the same four or five causes, at more length.

"No usable flow was found"

The run ended before it had a demo — usually one beat, sometimes none. The page offers four things to try, and they are in the order that most often works:

1. Name the first click in your intent line. "Create a project and show it in the list" gives discovery a first move; "show projects" does not.
2. Point the URL at the screen the flow starts on, not at a marketing page. Exploration goes forward from where it lands.
3. Attach a saved login if the flow is behind one. A signed-out browser sees a sign-in screen and nothing else. See Recording behind a login.
4. Check the page loads for a stranger. A feature flag, an allowlist or a maintenance page will all produce this.

There is a fifth cause that is nobody's fault: the model occasionally returns a turn proposing nothing. The loop re-asks rather than giving up, so this is rarer than it was — but if a demo produces this and the same inputs work on a second attempt, that is what happened.

"A recorded element is no longer on the page"

A capture died because something the plan clicks has moved, been renamed, or been removed.

Demofy re-shoots this one for you, once, automatically. The failed job's page says so and links forward to the replacement, and the replacement's own build log says nobody pressed anything. It is a full re-exploration from your original URL and sentence — a new plan rather than a repair of the old one.

The automatic re-shoot happens at most once per demo, only for this failure, and only on demos Demofy itself explored. It spends no daily allowance and carries the tier you already bought.

If it happens repeatedly on one app, the honest reading is that the flow is genuinely unstable — a list whose first row changes, a modal that sometimes appears — and the fix is an intent line aimed at something more stable, or a URL that puts the app in a known state.

Before that point, Demofy tries hard not to fail at all. A recorded element that no longer resolves at its recorded position is looked up by its accessible role and name instead; a click blocked by a decorative overlay is forced through once, the way a person's click would land; an element that is present but below a menu's fold is scrolled to. Each of those is said aloud in the build log, and a build log full of them is a plan that is aging.

Nothing errored, but the demo stops one beat short

This one is not a failure and there is no message. The video shows the form filled in and never shows the thing being created, because the beat that presses Enter was never proposed.

Two fixes, both quick:

• Rewrite the intent line to name the end state. "Add a todo and show it in the list" gets the keystroke; "add a todo" sometimes does not.
• Or make the demo, then trim. If everything else is right, the missing beat is one refresh away and the rest of the plan is already good.

The login had gone stale

A job that names a saved session is checked before it runs, and refused early if the session lands exactly where a logged-out visit landed. Re-establish the connection — Settings → Connections → Open live browser — and make the demo again.

Sessions rot on their own if you do not use them: unused for 30 days, a connection is deleted.

It never started

• Sitting in "queued"? You are at the in-flight cap: 2 jobs at once as a guest, 4 with an account. It starts when one finishes.
• Refused at creation with a rate limit? The daily bound — 3 a day as a guest, 10 with an account, over a rolling 24 hours. See Daily limits and the in-flight cap.
• Refused with an upgrade message? You asked for High or Ultra on a workspace that is not Pro. Standard is free and is the full pipeline.

"ORPHANED" in the log

The worker running the job died mid-render — a deploy, a restart, a kill — and a sweep noticed the silence and closed the row. It is not about your app and there is nothing to fix. Make it again.

The video is silent

Check the editor's voiceover switch first: off is a real setting, and a demo with it off writes no captions and no transcript either.

If it is on and the video is still silent, the build log says how many takes were spoken and how many were silent. A silence is what the pipeline produces when no speech credential is configured for the deployment: the beat is paced correctly and the mix says so rather than letting a mute video report success.