Lovable app blank after publishing: the fixes

As of October 10, 2026, when a Lovable app works in the editor preview but the published link shows a white page, check four causes in this order. The live site may be an older snapshot, because Lovable only updates it when you click Publish changes. A JavaScript error may be crashing the whole page, and the browser console will name it in red. The app may not reach its backend, because the built-in backend paused when credits ran out, a Supabase project paused, or a key changed. On a custom domain, DNS may not have finished. A 404 when you refresh an inner page usually means the app is hosted outside Lovable without a fallback rule.

This guide is for founders whose published Lovable app shows a white screen, a 404, a not-found page or a spinner that never stops. It goes symptom by symptom and shows you how to read the error yourself. Platform facts come from the official Lovable, Supabase, React, browser and hosting documentation listed under Sources.

What should you check first?

1. 01Check Lovable's status pageLovable posts platform-wide incidents at status.lovable.dev. If there is one, wait before changing anything.
2. 02Check the live site is published and currentOpen the Publish dialog. A dot on the Publish button means changes are waiting to go live. Build errors need fixing means your latest changes failed to build.
3. 03Rule out an old copy in your browserHard refresh with Cmd+Shift+R on a Mac or Ctrl+Shift+R on Windows, then try a private window.
4. 04Read the first red error in the consoleThe next section shows how.
5. 05Check the backend is awakeOn Lovable Cloud, open More, then Cloud, then Overview, and click Wake up if it is paused. On your own Supabase project, check the Supabase dashboard.
6. 06Check the custom domainOpen Project, then Settings, then Domains. Any status other than Live comes with instructions.

How do you open the browser console in Chrome or Safari?

The console is a panel in your browser that lists the page's errors. You only need to copy one line.

• Chrome: on the broken page, press Cmd+Option+J on a Mac or Ctrl+Shift+J on Windows. Or right-click the page, choose Inspect and click the Console tab.
• Safari on a Mac: once, go to Safari, Settings, Advanced and tick Show features for web developers. Then press Option+Command+I, or choose Develop, then Show Web Inspector, and click the Console tab.
• Reload the page with the console open, so it catches errors during loading. Copy the first red line exactly, including any file name.

Lovable's debugging guide uses this exact case as its example: a blank published app, with a TypeError from the console pasted into the project chat. Lovable reads the preview's console itself, but pasting the exact error helps when it happens on your live site.

What does the error in the console mean?

Why does the preview work when the published site does not?

Because they are different copies. Lovable's docs describe the preview as your latest working version and the published site as a snapshot of your last publish. So "it works in preview" often means the fix is not live yet.

Some settings are fixed when the app is built. Values whose names start with VITE_, such as VITE_SUPABASE_URL, live in the project's .env file and are built into the browser code, so a changed value reaches the live site only when you publish again. Secret keys belong in More, then Cloud, then Secrets, where only the backend reads them. Lovable's docs say deleting a secret a feature still uses breaks the app until you add it back.

Why does one JavaScript error leave the whole page blank?

Lovable's docs explain that older Lovable apps, built on React and Vite, send the browser a mostly empty page and build the content with JavaScript. React's documentation says that by default, if an app throws an error while rendering, React removes its interface from the screen. One bad line can leave visitors with nothing.

The safety net is an error boundary: a component that shows a fallback, such as a message and a reload button, instead of the part that crashed. React notes they do not catch errors in event handlers or delayed code, so they contain a crash rather than fix it. The community prompts in Lovable's debugging guide recommend them so one failing component does not crash the whole page.

Lovable's docs say TanStack Start became the default for new projects on May 13, 2026, and apps created since then use server-side rendering: the server sends each page as finished HTML. That changes what arrives first, not whether code can fail. On those projects, Lovable's logs, under More, then Cloud, then Logs, include server logs. Ask Lovable which stack your project uses.

A prompt can fix code errors and add error boundaries. It cannot change DNS at your registrar, resume your own Supabase project, add credits, or change settings on a host outside Lovable.

Why do inner pages show a 404 when you refresh?

Almost always because the app is hosted outside Lovable. Lovable's hosting has nothing for you to configure; if a page 404s there, ask Lovable in Chat mode whether that address still exists in the app.

An older React and Vite app is static files with one real page, index.html; the app draws every other page in the browser. Open /dashboard directly and the host looks for a file that does not exist. Lovable's deployment guide says to add a fallback rewrite so every route serves /index.html. On Netlify, that is one line in a _redirects file: /* /index.html 200. On Vercel, it is a rewrite in vercel.json from the source /(.*) to the destination /index.html.

A TanStack Start app needs a host that runs its server part; Lovable's guide says a 404 on refresh there usually means the host is not running it. Its test before switching traffic: open an inner page directly and refresh. Our guide to moving off Lovable Cloud covers self-hosting in full.

Is your custom domain finished and pointing at Lovable?

Custom domains need a paid Lovable plan. For a domain you already own, Lovable asks for an A record pointing to 185.158.133.1 and a TXT record at the host _lovable (or _lovable.blog for a subdomain like blog) whose value starts with lovable_verify=. Remove any AAAA records, which Lovable says can misroute traffic. DNS changes can take up to 72 hours, though most are live within a few hours.

If the domain shows your old website, old A, AAAA or CNAME records are still in place. On Cloudflare, error 1001 or 1003 means Lovable's records are proxied: set them to DNS only. Lovable will also report the domain's state and expected records if you ask in the project chat. If sign-in fails on the new domain, see our guide to Google login not working in Lovable.

Could your backend be paused or your keys changed?

• Lovable Cloud: when a workspace has no credits left at all, the built-in database, storage and sign-in pause shortly after. The site stays up but cannot load data; your data is kept. Add credits, then click Wake up under More, Cloud, Overview if needed.
• Your own Supabase project: Supabase pauses Free Plan projects that show low activity over a 7-day period. Open the project in the Supabase dashboard and click Resume project. Supabase does not pause paid projects for inactivity.
• Changed keys: Supabase is retiring its legacy anon and service_role keys by the end of 2026; they stay valid until you disable them in Settings, API Keys. The browser key is built into your published code, so after replacing it, update .env and publish again.

How do you stop a blank page reaching customers again?

• After every publish, open the live site in a private window, on a computer and a phone, including one inner page.
• Keep an error boundary around each page, so a crash shows a message, not white space.
• Lovable's History panel marks the live version with a Published badge, so you can revert and republish if a publish broke something.
• On Pro plans and above, project monitoring, in beta, checks recent visitor errors on a schedule. It does not replace testing.
• Add error tracking that alerts you when visitors hit errors. That is part of observability.

If the site loads for you but Google shows it blank or does not list it, see our guide to Lovable SEO. The wider launch list is in taking a Lovable app to production.

When should you stop prompting and get help?

• Paying customers cannot use the app, and none of the causes above fits.
• The blank page comes back after every publish.
• The console error points into code nobody can explain.
• The app is hosted outside Lovable and deploys keep failing.
• You think a key leaked. See our guide to an exposed Lovable API key.

Our vibe-coding rescue service finds the real cause before changing anything. To see where your app stands first, take the free production-readiness check.

Plans and what they include are on our pricing page.

Sources

All checked on October 10, 2026.

• Lovable documentation: Publish your Lovable project, on snapshots, Publish changes, build errors and publish failures (docs.lovable.dev/features/publish).
• Lovable documentation: How Lovable hosts your app, on server-side rendering for apps created from May 13, 2026, the status page, the Free plan request limit and paused backends (docs.lovable.dev/features/hosting).
• Lovable documentation: Upgrade a project to TanStack Start, on the default date and what server-side rendering means (docs.lovable.dev/features/upgrade-to-tanstack-start).
• Lovable documentation: Preview and test your app, on the preview versus the published site and hard refresh (docs.lovable.dev/features/projects/preview).
• Lovable documentation: Debug and improve your app, on pasting console errors from the published site and error boundaries (docs.lovable.dev/prompting/prompting-debugging).
• Lovable documentation: Secrets, on secrets versus VITE_ values and the .env file (docs.lovable.dev/features/secrets).
• Lovable documentation: Set up a custom domain, on DNS records, statuses and troubleshooting (docs.lovable.dev/features/custom-domain).
• Lovable documentation: Deploying and hosting outside Lovable, on the two stacks, the index.html fallback and testing before switching traffic (docs.lovable.dev/tips-tricks/external-deployment-hosting).
• Lovable documentation: Credits and usage, on backends pausing at zero credits and Wake up (docs.lovable.dev/introduction/credits-and-usage).
• Lovable documentation: Logs, and Revert and restore your project with version history (docs.lovable.dev/features/logs; docs.lovable.dev/features/projects/history).
• Lovable documentation: Project monitoring, on visitor error checks and their limits (docs.lovable.dev/features/project-monitoring).
• Supabase documentation: Project Pausing, and API keys (supabase.com/docs/guides/platform/free-project-pausing; supabase.com/docs/guides/getting-started/api-keys).
• React documentation: Component, on catching rendering errors with an error boundary (react.dev/reference/react/Component).
• Google: Open Chrome DevTools (developer.chrome.com/docs/devtools/open). WebKit: Enabling Web Inspector, for Safari (webkit.org/web-inspector/enabling-web-inspector).
• Mozilla: MDN Web Docs, Mixed content (developer.mozilla.org/en-US/docs/Web/Security/Mixed_content).
• Netlify documentation: Rewrites and proxies, on single-page apps (docs.netlify.com/routing/redirects/rewrites-proxies). Vercel documentation: Vite on Vercel, on SPA rewrites (vercel.com/docs/frameworks/frontend/vite).