Lovable App Not Working? What to Try, and When to Get Help

When a Lovable app stops working, first rule out Lovable itself on its status page. After that, the cause is usually one of a short list: a build or publish error, a login redirect misconfigured in Supabase, row-level security blocking or exposing data, a custom domain or GitHub sync problem, a Stripe key or price ID in the wrong mode, an AI edit that broke something that worked, or running out of credits. Most of these you can fix yourself in under an hour by reverting to a working version and checking settings rather than prompting again. Bring someone in when the same problem returns after a revert, or when the fix involves security policies or payments you cannot verify.

Each section below gives the symptoms, what to try yourself, and the point at which it is worth paying someone. Facts about Lovable and Supabase are from their documentation, checked on 20 October 2026.

At a glance

Step zero: is it Lovable, or your app?

Before you change anything, open status.lovable.dev. It lists Lovable's components separately, including the website, login, the editor, hosting, published customer sites, preview links, Cloud, the API and MCP, and you can subscribe to updates. If a component you depend on is degraded, local fixes will not help and prompting only spends credits.

If everything is green and the editor itself will not load or the preview will not update, rule out your browser: reload without the cache, try a private window, and switch off extensions that block scripts or connections. If it still fails and you are on a paid plan, Lovable's troubleshooting guide says to contact Support when you believe the problem is with Lovable itself.

Collect the evidence before you prompt

Most fix loops start with a vague prompt. Spend five minutes on this first, because every later step uses it:

1. The exact error. Copy the full text from the activity card, the browser console (right-click, Inspect, Console) or the network tab. A screenshot of a red box is not enough.
2. Where it happens. Preview, published site, or both; which page; which user.
3. What changed. The last prompt or setting before it broke. The version history shows it.
4. The request. For data problems, find the failed request in the network tab and note its status code (401, 403, 404, 500) and response body.
5. The logs. For anything involving payments or email, the Edge Function logs and Stripe's Developers, Logs page.

Then use a narrow prompt. This template keeps the change small and tells Lovable what must not move:

Investigate before changing code (Plan mode).
Problem: [exact error text] on [page], in [preview / published / both].
Expected: [what should happen]. Actual: [what happens].
Started after: [last change].
Evidence: [status code and response from the network tab, log lines].
Constraints: change only [file or component]. Do not change
database policies, authentication, or payment code. Do not
turn off row-level security or add policies that use true.
First explain the root cause, then propose the smallest fix.

Build and publish errors

Symptoms: a build error on the activity card, the preview will not load, or the Publish dialog refuses to publish.

Try yourself. Lovable's troubleshooting guide says a "Try to fix" button appears on the error, and that your account includes 10 free fixes, shared with fixes from the Security view, each available again 24 hours after use. While the latest build fails, publishing is blocked. Its debugging guide gives the rule worth following: use Try to fix once or twice, then "stop retrying blind fixes" and ask Lovable to find the root cause in Plan mode before changing more code.

If fixes have tangled the code, go back rather than forward. Lovable offers Undo latest edit, Revert to this version on an earlier response, and Edit message then Revert and resend to rewrite the request that caused the problem.

The 10 MB error. The same guide says single files larger than 10 MB cannot be saved into a project's code, which usually happens after adding large images or videos. Ask Lovable to "Migrate large files to CDN assets", and it moves them and updates the code.

If it works in the preview but not on your own hosting, check which stack you have. Lovable's external hosting guide says older React and Vite apps build to static files and need the host to fall back to index.html for client-side routes, while newer TanStack Start apps need a server and do not run from a CDN or object storage alone. It also notes that VITE_ variables are embedded at build time, so you must rebuild after changing them.

Bring someone in when the same error returns after a revert, or the error mentions types, dependencies or the build tool rather than your feature.

Login loops and auth problems

Symptoms: you sign in and land back on the login page; password reset or confirmation emails link to localhost or the old domain; Google sign-in works in the preview but not on your domain.

Try yourself. Two settings decide where a signed-in user lands, and Supabase's redirect URL guide describes both:

• the Site URL, the default address after sign-in, which Supabase calls "critical for email confirmations and password resets";
• the Redirect URLs allow list: every address the app may send users back to, including your custom domain. Supabase recommends exact paths in production and wildcards mainly for local and preview URLs.

Where you set them depends on your backend. Lovable's authentication docs say that on Lovable Cloud both are under Auth settings, Advanced, and that Lovable keeps them up to date when you publish or connect a custom domain, unless you set the Site URL yourself, in which case it stays as you set it. On your own Supabase project there are no automatic updates: add every address in that project's auth settings. If you use your own Google OAuth credentials, a new domain also needs a redirect URI in Google Cloud Console.

Also check your email templates: Supabase notes that when you pass a redirect, you may need {{ .RedirectTo }} in the template instead of {{ .SiteURL }}.

Bring someone in when sessions drop at random, users see each other's data after signing in, or roles behave differently from what the interface shows. Those are security problems, not configuration ones.

Supabase errors and missing data

Symptoms: a list that should have data is empty, an update silently does nothing, a form says it saved but the table is empty, or the console shows "permission denied" or code 42501.

Try yourself. Supabase's row-level security guide explains the behaviours behind most of these:

• once RLS is enabled, "no data is accessible through the API" with the public key until you create policies, so an empty result often means a missing select policy, not missing data;
• "to perform an UPDATE operation, a corresponding SELECT policy is required", so an update with no select policy appears to do nothing;
• auth.uid() is null when the request is not logged in, so a policy comparing it to user_id never matches for a signed-out user;
• an insert whose with check clause does not match the new row is refused, and generated code does not always show that error to the user.

Check the policy for the exact operation that fails (select, insert, update or delete are separate), and confirm the user is signed in when the request is made.

New tables and "permission denied for table". Supabase is changing a default: its changelog says new tables in the public schema are no longer exposed to the Data API automatically. That became the default for new projects on 30 May 2026 and is applied to all existing projects on 30 October 2026. Existing tables keep their grants. A table created after the switch, by a migration or a prompt, answers with error 42501, "permission denied for table", and a hint naming the GRANT to run. The fix is the grant for the roles that need it, then RLS and policies as usual; the changelog says RLS behaviour is unchanged. If you use Lovable Cloud rather than your own project, check whether the error appears before assuming it applies to you.

The dangerous fix to avoid: when a query returns nothing, the quickest prompt is "make the data load", and the quickest code change is a policy of true or turning RLS off. The error goes away and the table becomes readable by anyone with the public key. That is the pattern behind CVE-2025-48757. If a fix touched a policy, read it before you publish. Our Supabase RLS checklist shows what a correct one looks like.

Bring someone in if you cannot tell whether a policy is right, or the data model has teams, organisations or shared records.

A worked example: the form that saves nothing

A founder adds a "Request a quote" form. It shows "Thanks, we'll be in touch", but the quotes table stays empty. Prompting "fix the form" twice produces new styling and the same result.

Working through the evidence instead:

1. The network tab shows a request to /rest/v1/quotes returning 403, with a message about row-level security. So the database refused the row; the form ignored the response and showed success anyway.
2. The policies tab shows a select policy on quotes but no insert policy. RLS is on, so every insert is refused.
3. The form is for signed-in customers, so the right fix is an insert policy for authenticated with with check ((select auth.uid()) = user_id), and the form must send the user's ID. The wrong fix, a policy of true, would let anyone insert anything, including rows claiming to be someone else's.
4. A second, separate change makes the form show an error when the request fails, so the next silent failure is visible.

Two narrow prompts, each reviewed, instead of a loop of broad ones.

Custom domain problems

Symptoms: the domain never goes live, stays on "Verifying", shows an old site, or the certificate fails.

Try yourself. Lovable's custom domain guide gives the records and the common causes:

The verification TXT record uses the host _lovable (or _lovable.<prefix> for a subdomain). DNS changes may take up to 72 hours, though the guide says most are live within a few hours. If no certificate is issued after 72 hours, contact Lovable Support.

GitHub sync errors

Symptoms: commits stop appearing in GitHub, or changes made in GitHub stop appearing in Lovable.

Try yourself. Lovable's GitHub guide covers the causes:

• The repository was deleted. That stops the sync, and reconnecting creates a new repository rather than reusing the old one. Renaming the repository, your account or your organisation keeps the sync running.
• The repository was transferred. Sync continues only if your workspace has a GitHub connection for the new owner.
• GitHub rejected the push, usually because of branch protection or a conflicting change. Lovable then pushes its work to a lovable-sync branch for you to merge.
• Someone deleted the synced branch on GitHub.
• Your organisation uses an IP allow list. Add Lovable's IP ranges to it.
• A file over 100 MB. GitHub rejects the push.

Lovable edits one branch at a time, and you cannot switch branches while it is editing.

Payments failing

Symptoms: checkout does not open, payments fail, the customer portal errors, or customers pay and do not get access.

Try yourself. Lovable's Stripe integration guide lists the common causes:

• checkout does not open: usually a popup blocker;
• customer portal errors: activate the portal in the Stripe dashboard first; it does not work in the preview, so test in a standalone tab or on the published app;
• key rejected or "update the key" prompt: the key lacks permissions or was revoked;
• works in test, fails live: live price IDs are different from test ones, and the key you submitted sets the mode;
• checkout fails: read the function logs and Stripe's Developers, Logs page for the failed request.

Also note that the integration does not use webhooks by default. If something must happen after payment and it is not happening, you may need a webhook function, with its signing secret copied from Stripe.

Bring someone in before you change how access is granted after payment, or if customers have been charged without receiving what they paid for. Fix the cause, then reconcile in Stripe.

The AI broke something, or says it fixed what it did not

Symptoms: you asked for a small change and an unrelated feature stopped working; or Lovable reports a bug fixed and it is still there.

Try yourself.

1. Revert to the last version where both features worked; do not ask the AI to repair its repair.
2. Re-ask in Plan mode with a narrow request, using the template above: name the file or component, and say what must not change.
3. Ask Lovable to reproduce the bug before fixing it. Its troubleshooting guide says it can inspect errors, logs and console output, and test the app in a browser.
4. Verify the fix yourself on the path that failed, not only the one it tested.
5. Make one change per message, and test the paths you care about after each.
6. Connect GitHub if you have not, so every working state is a commit you can return to outside Lovable.

Bring someone in when this keeps happening. It is a sign the app needs tests on its core paths and a review step, which is a workflow change rather than a better prompt. See is Lovable production-ready for what that involves.

Credit burn, and an app that suddenly pauses

Lovable's credits documentation separates build credits (chat, Plan and Build mode messages) from run credits (Cloud, AI features in your app, connectors), all from one balance. Large generations cost more than small edits, and fix loops multiply that. Traffic, stored data and file transfers raise run usage.

Mid-task: the troubleshooting guide says that if credits run out during a task, Lovable pauses the message and offers Add credits to resume or Finish up to complete the work in progress and stop. Closing the browser does not stop a task, because requests run on Lovable's servers.

Try yourself: use Plan mode before Build mode, keep edits small, check the cost under each reply, and set usage limits and alerts. The same page says that when a workspace runs out, AI features in deployed apps stop and Cloud apps pause, so an app that stops overnight with no code change may simply have run dry. On Pro and above, project monitoring can check the project on a schedule and post in chat when it finds a problem; it is off by default.

Bring someone in when run credits, not building, are most of your spend. That usually points to slow queries or chatty code, which a developer can measure and fix.

Common mistakes that make it worse

• Clicking Try to fix again and again. Each attempt can add code that hides the cause.
• Prompting during an outage. Check the status page first.
• Fixing empty data with true. It works instantly and exposes the table.
• Testing payments only in the preview. The customer portal does not work there, and a live key makes preview payments real.
• Changing DNS at the old host and the new one at once. Leave only the records Lovable asks for.
• Deleting the GitHub repository to start fresh. It stops the sync; reconnecting makes a new repository.
• Asking for a big rewrite to escape a bug. A large generation is the most likely to break something else.

When to stop fixing and get help

Get help when any of these is true:

• the same failure has come back after two reverts;
• the fix involves row-level security, roles or who can see what;
• money is involved: failed charges, missing access, refunds;
• you no longer know which version of the app is the good one;
• you are spending more credits fixing than building.

When not to hire us: if the app is a prototype for user interviews and it fails on an edge case nobody hits, note it and keep testing your idea. And if it is a single settings problem from the list above, fix it yourself; you do not need us.

If you do want a person to look, the €99 Prototype Check reviews the repository and live app and sends the top risks in writing within 48 hours of payment and access, then a 15-minute call. The €99 is credited against the build if you hire us. If the app is failing because it has outgrown Lovable, read when to move off Lovable. We are based in Budapest and work remotely across Europe on CET, with our engineering team in India.