Lovable App Not Working? Here's How to Fix It

Which of the six failures is yours?

Six failures produce almost every 'Lovable app not working' report, and they share no root cause. A blank preview, a build that fails, an app that worked yesterday, generation that never finishes, an error on the deployed site, and a change that broke what was working each need a different first move. Match the symptom below, then open the guide that owns it.

Routing matters more than triage speed here, because five of the six have a fix that does nothing for the other five. Reverting a checkpoint will not add a missing environment variable to your host. Adding an environment variable will not clear a TypeScript compile error. Reading the symptom correctly is the whole first step.

The preview is blank or white

A blank preview is a runtime error inside the editor sandbox, most often a broken import or a syntax error introduced by the last generation. It does not mean the deployed build is down, so open the pop-out preview first and check whether your users are affected at all. Then read the browser console for the red line that names the file. Full triage: Lovable's blank white screen.

The build fails

A failed build is a compile error, not a mystery. The build log names the file and the line the TypeScript compiler rejected, and exit code 1 is the compiler's way of saying it refused the generated code. Read that line before re-prompting, because re-running the generator against a compile error it cannot see usually produces a second one. Full triage: exit code 1 build failures.

It worked yesterday and I changed nothing

When nothing in the editor changed, the change was in the environment: a variable that no longer resolves at build time, a platform update to the toolchain, or a key that expired. The tell is that the editor still looks fine while the deployed build fails. Diagnose the environment before you touch a prompt, because reverting code does not restore a missing variable. Full triage: a Lovable app that worked yesterday.

Generation is stuck and never finishes

Two different stalls hide behind one symptom, and they recover differently. A spinner showing no percentage means the generation request never returned, and reloading the editor is the first move. A stall that parks on a percentage means the run started and stopped part-way through a set of file writes. Full triage: generation stuck on thinking and a build stuck at 80 percent.

The deployed site errors but the editor is fine

Preview and production run in different environments, so a live-only failure is almost always configuration rather than code. The two usual causes are environment variables that exist inside Lovable but were never added to the host, and a missing SPA rewrite that turns any refreshed deep route into a 404. Neither is fixed by a prompt. Full triage: when preview works but the live URL breaks.

The last change broke what was working

Revert first and diagnose second, because the timeline restores the code that worked and it costs no credits. The catch worth knowing before you click: reverting restores your project's code only, so any table, column or row that the broken change created stays exactly as it is. Full triage: rolling back without losing your data.

Why did my Lovable app suddenly stop working?

The most common cause is a prompt change that touched more files than intended. When Lovable generates code, a single prompt can modify dozens of files at once — and one bad edit to a shared component, a config file, or an import path is enough to bring down the whole preview. The good news: it is almost never permanent.

Other common triggers include a Supabase environment variable that changed, an edge function that hit a timeout, or a dependency version that was silently updated during a build. Before assuming your app is destroyed, rule these out one by one — start with the most recent change and work backward.

This cycle has a name: the **Bug Doom Loop** — the cycle where each Fix attempt spends a credit, generates new file changes, and often introduces a second error while resolving the first. Recognising you are in this cycle early is the single most important skill for Lovable builders.

Related: Bug Doom Loop (glossary)

How do I tell if it's the editor preview or my real app that's broken?

Open the deployed build pop-out preview — the icon in the top right of the editor — and see if your real app loads. The editor preview and the deployed build are separate; a white or blank editor preview does not mean your deployed build is broken. If the pop-out loads correctly, only the editor sandbox is affected, not what your users see.

If the pop-out shows a blank screen too, open browser DevTools (F12) and look at the Console tab. Real runtime errors appear as red lines naming the file and line number. A message like `Cannot find module './auth/useSession'` points directly to the broken import. Copy that string before doing anything else.

Related: fix a Lovable preview stuck on a white screen

What's the fastest way to get back to a working version?

Go to your project timeline or version history and identify the last prompt before things broke. Revert to that checkpoint before making any more edits or clicking Fix. Every additional prompt you run without a stable base risks compounding the damage — and spending credits. Restore first, then diagnose what went wrong with a fresh eye.

1. Open the project timeline (clock icon in the left sidebar).
2. Find the last version where the app was working — check the preview thumbnail.
3. Click Revert to restore that checkpoint.
4. Open the pop-out preview to confirm the restored build loads correctly.
5. Only then, make one small change at a time and re-test before continuing.

Why does clicking 'Fix' keep making it worse?

The Fix button sends a new prompt to Lovable to repair the error it detects. Each attempt spends a credit and generates a new set of file changes — which can introduce a new error. Once an app has 30 or more files, a single prompt routinely touches unintended areas. If Fix has failed twice, stop: you are likely deepening the problem, not solving it.

This is the **Bug Doom Loop** in its clearest form. Each click signals the AI to try a new approach without memory of what the previous Fix attempts changed. The codebase accumulates layers of partial fixes, and tracing which one caused which breakage becomes nearly impossible without returning to a clean checkpoint. Builders who have lost track of how many Fix credits they have spent are almost always well inside the loop.

Those layers do not disappear once the app runs again. Dead files from abandoned prompts, duplicated logic and swallowed errors stay in the repo and are what make the next bug harder to find, which is why the pre-launch cleanup pass is worth doing after a bad loop rather than only before launch.

A related failure mode is **false-fixed hallucination** — Lovable responds 'The issue is now fixed' when the error has merely shifted to a different component. If your tests still fail or the behaviour is still wrong after a 'fixed' response, do not run another prompt: revert and isolate.

How do I confirm my app is actually fixed?

After reverting or making a targeted change, run this verification sequence before calling it done. One test on the happy path is not enough — the most common failure mode is a fix that works in the editor preview but breaks in the deployed runtime or under a real user session.

This sequence proves the break is gone. It does not prove the app is ready for anyone but you — a preview session tests one user against an empty database. When the fire is out, our Lovable production readiness scorer walks the same app across security, database, reliability, code quality and performance and returns the gaps in priority order, with security weighted highest.

1. Open the pop-out deployed build and confirm the root route loads without console errors.
2. Open browser DevTools (F12 → Console) and verify there are no red errors on load.
3. Navigate to the specific feature that broke and exercise it — submit the form, click the button, trigger the data load.
4. Check the Supabase dashboard to confirm any expected writes actually appear in the table.
5. Sign out and sign in again to verify auth state is clean and the session persists correctly.
6. If the app uses Stripe, trigger a test event from the Stripe dashboard and confirm the webhook response is 200.

When should I stop self-fixing and get a human?

If you have reverted to a checkpoint and the same break reappears, or if Fix has failed three or more times, the root cause is structural — not something prompt iteration can safely unwind. A senior engineer can diagnose the exact file and line causing the failure, restore a working build without burning more credits, and leave you with a written explanation of what went wrong.

Signs it's time to escalate: the error message is cryptic TypeScript or build output you don't recognise; the break reappears after every revert; or you've lost count of how many Fix credits you've spent. Getting a specialist in early is almost always cheaper than continuing to guess. If this is the third app in a row that has broken this way, the more useful question is whether vibe coding itself is the problem — prompting without reading the code is genuinely good for prototypes and genuinely risky once real users, real data or real money are involved.

**Context rot** — the AI losing track of earlier decisions after editing several files in one session — is the structural signal that self-fixing will not work: once Lovable has edited a handful of files, it tends to forget architectural decisions made in the earlier ones. Any further prompting compounds that drift. A human engineer reads the actual source files, not a prompt context window.

Related: read the build log behind exit code 1 and fix the real error