Your Lovable app worked yesterday. Now it’s broken — what changed?
Most broken Lovable apps trace back to a short list: the published snapshot is stale and needs a republish, a build or runtime error is blanking the screen, Supabase auth redirect URLs still point at the wrong domain, Stripe only works after deploy by design, an edge-function secret is missing, or row-level security is silently returning empty data. Work the checks below in order — most are fixable in one sitting.
Preview and published are two different worlds
Lovable's preview rebuilds constantly; the published site is a snapshot you deployed once, backed by Supabase for auth, data, secrets, and edge functions. Almost every "it broke" report lives in the seam between those two: a snapshot that's behind, a Supabase setting still pointing at the old URL, a secret that exists in one place and not the other, or a security rule that behaves differently for a real user than for you in the editor.
Seven ways a Lovable app breaks — symptom, then fix
Blank or white screen on the published app
Symptom: The live URL loads, but the page is empty. Preview may look fine.
Fix: Open the browser console on the live URL — the real error is there. Lovable's docs point at vite.config.ts issues or security headers added to the project, plus build and runtime errors: ask Lovable to review vite.config.ts or remove the headers, or revert to an earlier version. If the console is clean, check status.lovable.dev — published-app blank pages have been platform incidents, and republishing resolved them.
Works in preview, broken (or stale) after publish
Symptom: Fixes you made are missing on the live site, or the live site errors where preview doesn't.
Fix: Publishing deploys a snapshot — future changes are not automatically published. Hit Publish → Update to republish. Publish failures are caused by build issues in the current version, so fix the build error preview shows first.
Login or magic link fails, or redirects to the wrong domain
Symptom: Sign-in emails point at localhost or the preview URL, or the link lands on an error.
Fix: Lovable auth is Supabase auth. Supabase's Site URL defaults to http://localhost:3000, and every redirectTo must be in the Redirect URLs allowlist. In Supabase Authentication settings, set the Site URL to your published domain, add preview and production URLs to the allowlist — and click Save; Lovable's own guide notes many people forget that step.
Stripe does nothing in preview
Symptom: Checkout buttons are dead or payments never start in preview.
Fix: By design: Lovable's docs state the Stripe integration doesn't work in preview — deploy to test it. Lovable scaffolds payments as Supabase Edge Functions; test with Stripe Test Mode first, keep webhook signing secrets in Supabase → Edge Functions → Manage Secrets, and debug via the edge-function logs plus the Stripe Dashboard delivery logs.
A secret or API key is missing on the server side
Symptom: A feature that calls an external API fails after publish, often with a 500 from an edge function.
Fix: Lovable stores credentials in Supabase's Edge Function secret manager — it prompts for them when a feature needs one. If a key was rotated or never saved, re-add it there (never paste secret keys into the chat), then re-run the failing flow and watch the edge-function logs.
Queries return empty after enabling RLS
Symptom: Lists and dashboards are blank for signed-in users; no error anywhere.
Fix: Supabase documents this exactly: once RLS is enabled, no data is accessible via the API with a publishable key until you create policies. Write a policy per table for the roles that should read/write. Lovable can generate basic RLS policies if you prompt it — then verify as a real user, not just in the editor.
Google sign-in fails with an OAuth client error
Symptom: Google login errors out or refuses the redirect after you switched to your own credentials.
Fix: With bring-your-own Google credentials, the OAuth client must be a Web Application type — Desktop or Mobile client types fail. Create a Web Application OAuth 2.0 client in Google Cloud Console, add the redirect URIs, and enter the Client ID/Secret under Cloud → Users → Auth → Google. Or stay on the managed mode, where Lovable handles redirect plumbing.
Paste this into your incident notes
Lovable app triage
[ ] Open the PUBLISHED URL (not preview) in incognito; check the browser console.
[ ] Check status.lovable.dev for an active platform incident.
[ ] Republish: Publish -> Update. Confirm the build succeeds.
[ ] Supabase Auth settings: Site URL = published domain; redirect URLs allowlisted; SAVED.
[ ] Supabase -> Edge Functions -> Manage Secrets: every key the app needs is present.
[ ] Stripe: testing in preview? It only works after deploy. Use Test Mode first.
[ ] RLS: policies exist for every table real users read/write; test as a real user.
[ ] Google OAuth (own credentials): client type is Web Application; redirect URIs added.
[ ] Still stuck: revert to the last known-good version and republish.How Nightlamp catches this before your users do
Every failure on this page is invisible from the editor — the preview keeps working while the published app breaks. So the checks have to run against the published URL, as a stranger: a browser_journey that loads the live site and asserts real content rendered (a blank screen fails it), an email_flow that requests a magic link and follows it to a logged-in state, an api_canary that reads data the way a signed-in user would — which is what catches RLS silently emptying your tables — and an http_keyword watching the published snapshot for the marker your latest release should contain.
Lovable troubleshooting FAQ
Why is my Lovable app a blank screen after publishing?
Lovable's troubleshooting docs point to vite.config.ts issues or security headers introduced into the project, plus build and runtime errors. Check the browser console first, ask Lovable to review vite.config.ts, or revert. Platform incidents have also blanked published pages — republishing resolved those.
Why does it work in preview but not published?
Publish deploys a snapshot; later edits aren't live until you republish (Publish → Update). And Stripe is a special case: it doesn't work in preview at all by design — deploy to test payments.
Why do login emails send users to localhost or the preview URL?
Supabase's Site URL defaults to http://localhost:3000 and redirect targets must be allowlisted. Set the Site URL to the published domain and add redirect URLs in Supabase Authentication settings — and save.
Why is my data gone after enabling row-level security?
With RLS on and no policies, Supabase returns empty results — no error. Create policies for each table and role, then test as a real signed-in user.
What URL does my published app live on?
your-subdomain.lovable.app by default; custom domains need a paid plan, and the .lovable.app URL stays as a permanent fallback.
Want the 3 a.m. republish caught for you?
Point Nightlamp at your published Lovable URL and the flows that matter — login, checkout, the data your dashboard reads. When the published app breaks while preview looks fine, you get a diagnosis, not just a red light.
Start 14-day trial · no cardNewsletter
One real no-code incident + the fix, monthly
A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.
Double opt-in. One-click unsubscribe. No spam, ever.