Skip to content
All guides

Troubleshooting·Updated September 19, 2026·6 min read

Why is my preview blank?

A blank preview is a runtime error nine times out of ten. Here is the sentence that gets it diagnosed in one turn, and what to reset when it is genuinely wedged.

Reference documentation

The preview is your project's dev server running in an iframe. A blank white screen almost always means the app threw before it rendered anything — a bad import, an undefined read during the first paint, a provider missing above a hook. The console knows; you just have to ask for it.

Type this first

"The preview is blank. Read the runtime errors and tell me what's throwing."

On a broken preview the agent's first move is to read the console the preview has already captured — no browser round trip, no waiting. It only opens a browser when that log does not explain the failure, or when you ask it to.

That second half matters more than it looks. Verification is on-demand. The agent does not self-review its work and does not drive a browser unless your prompt says so. If you want proof rather than a claim, ask for it in words: "Test the login flow in the browser and tell me what you saw."

What is already checked on every turn

Runs every turn, no prompt neededOnly when you ask
TypeScript type-check of the projectClicking through a flow in a browser
Web: every route loaded in a headless browser to catch runtime errorsA screenshot to judge how something looks
Mobile: the Metro bundle gateChecking a form actually submits
Failures handed back to the agent to fix before the turn endsChecking a fix on a real device

So "I've fixed it" means the code type-checks and the routes load. That is a real gate, and it is not the same claim as "the button works".

Describe it in four lines

If the first answer misses, the fastest correction is a better report: steps, expected, what actually happens, and where — preview or published, web preview or a real device, which browser. That last line often names the cause by itself. "Started after the turn where we added validation" narrows the search to one diff.

Paste errors verbatim — the full message and stack. A retyped error loses the file, the line and the exact identifier, which is most of the information.

When it is not an error but a stale view

  • Reload in the preview bar remounts the iframe and re-probes the dev server. Use it when hot reload has clearly stopped landing.
  • Restart in the project menu rebuilds the sandbox from your current files. The preview URL does not change.
  • Edits normally land over hot reload in about a second, and the platform reloads for new files, config changes and dependency installs. If you routinely need a restart to see an edit, that is a bug worth reporting, not a workflow.
  • On a phone, a stale build is usually Expo Go holding an old bundle: shake the device, Reload, and re-scan the QR code if it does not come back.

Nearby symptoms, and the prompt that fits

SymptomType this
A button does nothing"This control is a no-op. Find every handler in this screen that isn't wired and fix them."
Works in preview, broken once published"It works in the preview and fails on the published URL. What differs between the two?"
Works in the web preview, broken on device"It works in the web preview but fails in Expo Go on my phone. That means it's native — investigate."
A query returns nothing but rows exist"Check the RLS policies and the grants on that table."
You do not believe the fix"Test it in the browser and tell me exactly what you saw, step by step."

If it keeps making the same wrong edit

Stop building and switch to plan mode. More build turns on a wrong mental model just reinforce it; a read-only diagnosis turn breaks the loop.

Build it while it is fresh

Vibely builds web apps and native iOS and Android apps from the same chat — the mobile ones run on a real handset over Expo Go before they ever reach a store.

Start from a template

Keep reading