Lovable publish not working: the six publish failures, and the custom domain that shows nothing

Lovable publish not working? Open the Publish dialog before you touch DNS. A Publishing failed banner means the deploy never finished, and it names one of six causes. A dialog that says Your website is live, with the lovable.app address loading, means the publish worked and the fault sits in your custom domain.

Lovable publish not working: which of the two things went wrong

A Lovable publish that is not working is one of two failures that look the same from outside: the deploy did not finish, or it finished and the custom domain is not serving it. The Publish dialog tells them apart, because it reports whether the last deploy completed.

Lovable’s own troubleshooting starts in the same place: check that the publish finished, then check that you are opening the exact published address. So when a Lovable website is not working after you pressed the button, match what you see to one of four rows before you change anything.

If the content is current and the app still behaves differently live than in the editor, that is code that only breaks once it is live, not a publish failure. Two neighbors are worth ruling out in one line each. Check whether Lovable itself is down before you debug your own project. And if this project has never been published at all, start with the steps for a first publish.

Every failure name, status and waiting time on this page comes from Lovable’s own documentation and status page as they read on 21 October 2026. Nothing was published and no domain was connected to produce it. Lovable renames things often, so hold each name against your own screen.

Lovable app not deploying: the six ways a publish fails

Lovable app deploys fail in six named ways, and the Publishing failed banner says which one. Three are fixed inside the project with Try to fix or the assistant, one is a short-lived problem that Try again clears, one needs a setting in another service, and one is an internal error on Lovable’s side.

The names and buttons below are the ones Lovable’s publish documentation lists. The last column is the one that saves time: it says whether anything you change in the project can help.

The banner is thin on purpose. Lovable says publish failure messages “never include raw logs or output from connected services,” with two exceptions: a build error shows a summary of the build failure, and a database conflict shows the database’s own error message. When the cause is a build error, the summary replaces the generic line, so the words in your banner may not match the table word for word.

The fourth row deserves its own paragraph, because it is the only one nothing inside Lovable will move. Lovable’s own examples are an expired Supabase connection and a connected service that reached its plan limits. The fix is in that service’s dashboard: reconnect the integration or update its plan or quota, then come back and click Try again. Keys and connection strings belong to the settings that live outside your code, which Lovable says it cannot change for you, so Try to fix is not the button for this row.

The fifth row is the careful one. Because the fix touches real data in the live database, Lovable confirms with you before it changes anything. Read what it proposes to do to existing rows before you agree.

A Lovable publish that ends with an internal error, the closest the banner set comes to an internal server error, is the last row, and the only move is to wait a few minutes and publish again. If it keeps happening, send support the project link; Lovable’s history page, covered further down, shows whether others hit it too.

Some walls arrive with no banner at all. Publishing from the dialog works even at a zero credit balance, but apps on the built-in backend (Lovable Cloud) or with AI features need available credits to serve requests, so a live app that stops answering may be a workspace paused for credits rather than a failed publish. Lovable can also unpublish a project in a Free workspace after 12 months without visits or workspace-owner logins.

Why the publish button is greyed out

The publish button is greyed out in Lovable, or replaced, when the dialog blocks publishing before any deploy starts. Lovable’s documentation lists four causes: a role below editor, changes that failed to build, an Enterprise workspace policy, and Block publishing with critical issues while critical security findings are unresolved.

The permission case is the easiest to confirm. Hover the button: if it shows “You don’t have permission to publish this project”, your role is the problem, because publishing needs editor access or above. Ask a workspace admin or owner to raise your access to the project.

A build failure looks different: the dialog shows Build errors need fixing and replaces the publish button with Try to fix. Fix the build, by that button or yourself, and publish once the preview builds again.

On Enterprise workspaces, admins and owners can set policies that require approval before publishing or block it. The dialog then shows Publish requires approval or Publishing is blocked by workspace policy and names the policy.

The last cause is a switch. Workspace admins and owners can turn on Block publishing with critical issues in Workspace settings → Security → Privacy & security, and while critical findings stay unresolved the dialog shows Fix security issues to publish. The Quick scan runs by itself when the dialog opens and takes about 10 seconds; by default its findings do not block publishing, so this block means the workspace has the policy on, and new Enterprise workspaces that Lovable creates start with it enabled. The switch says nothing about your app on its own: open the Security view, fix the critical findings, and the button returns.

Lovable custom domain not working: the statuses after a publish that worked

A Lovable custom domain that is not working after a successful publish has a status, and the status names the fix. Lovable’s custom domain page lists one for each step, from verifying DNS records to issuing the certificate, plus Ready for an unpublished project and Offline for records that changed after the domain went live.

Find it in Project → Settings → Domains, or ask Lovable in the project chat, which reports the state, how long the domain has been in it, which records it expects and whether it can see them. Two conditions come before any status: connecting a new custom domain requires a paid plan, and the domain starts serving only after the project is published. When your Lovable domain is not working, read its row in the table taken from Lovable’s custom domain documentation for a domain bought elsewhere.

A domain bought through Lovable has a shorter set: Pending, Action required, Suspended, Live, Ready, Checking, Connection issue, Check failed and Removed. Lovable creates its records itself, so the DNS rows above do not apply; Suspended most often means the registrant email was not verified before the deadline, and a suspended domain stops serving your project. If you want to publish to a custom domain you bought from Lovable, its setup typically completes within a few minutes but can take up to several hours.

Ready is the status people misread. Everything about the domain is correct, and the project simply is not published right now; publish it and the status turns Live by itself.

Offline and Connection issue are the two that appear after a domain already worked. Offline means the DNS records Lovable needs are no longer valid, and Recover shows the records it expects so you can put them back. Our reading of how that happens to a small team: someone moves the domain to a new registrar or sets up email and lets the new provider rewrite the zone. Connection issue covers the hosting side: Lovable lists a domain moved to another hosting service, a hosting record removed or blocked, a deleted SSL certificate, or a domain still connected to another project.

If launch is days away and nobody on your team owns the registrar account or keeps a copy of the DNS records, a free audit is where we go over with you who controls the domain and what to write down first. In the sprint, we enforce HTTPS everywhere with HSTS and a CAA record, lock the registrar, document the DNS records, and confirm renewal ownership.

How long a Lovable custom domain should take before something is wrong

A Lovable custom domain from another provider should leave Verifying within about an hour, and Lovable’s documentation allows DNS changes up to 72 hours to spread. We’d recheck the records once at about the hour mark, then leave them alone; a domain still dark at 72 hours with correct records needs a line-by-line comparison.

Lovable states both limits in one table row: “DNS verification did not complete within one hour”, and “DNS propagation can take up to 72 hours, although most updates are applied within a few hours.” Its launch guide adds a third: a domain whose records never arrive shows Removed after 72 hours.

Checks in the first minutes disagree for a reason. A DNS answer is cached for its time to live, and so is the answer that a record does not exist: RFC 2308 on negative caching says “Like normal answers negative answers have a time to live (TTL).” A lookup made before you saved the record can leave your own resolver remembering “does not exist” for a while after the record is there.

The one rule Lovable states firmly: the records “must remain unchanged until verification is complete,” and you should not enable proxying on the A record or point it at a CDN while verification runs. In its troubleshooting list, removing and re-adding the domain comes last, and for Stalled it says you do not need to.

1. 01 At about the one-hour mark, click Check status once and compare the A and TXT records at your DNS provider with the ones Lovable shows, the full TXT value included.
2. 02 Open the domain in a private window or after clearing the browser cache, so an old page or a cached answer does not mislead you.
3. 03 If the records match, leave them alone: no edits, no proxying on the A record, no remove and re-add.
4. 04 At 72 hours with correct records, treat the domain as broken: compare every record line by line, and contact Lovable Support if the certificate still has not been issued.

A working rule we use, built from Lovable’s one-hour and 72-hour lines: one check at the hour, then patience until 72 hours, then a careful comparison. If Check status answers “Hold on, we just checked this”, wait about five minutes before you try again.

Lovable proxy error and three other domain traps

Four domain traps make a connected Lovable domain serve nothing or the wrong thing: Cloudflare’s proxy turned on, a www address that was never connected, a leftover AAAA record, and A or CNAME records from a previous host. Lovable’s custom domain pages document all four.

A Lovable proxy error is, in the case Lovable documents, Cloudflare’s. Its page says of errors 1001 and 1003: “These errors come from Cloudflare’s proxy, not from Lovable.” If you want Cloudflare’s proxy kept in front of the site, Lovable’s launch guide gives the other route: disconnect the domain and connect it again with Advanced → Uses Cloudflare or similar proxy, which swaps the A record for a single CNAME.

The www trap now needs a setting turned off first. For a domain bought elsewhere, Lovable keeps the www redirect option on by default and connects www.yourdomain.com alongside the root; only someone who turned that option off sees Not connected.

The leftover-record trap has one guard worth repeating: remove the old A, AAAA and CNAME records for the address you connect, and leave MX and other record types alone, because they keep email on the domain working.

You never need to buy a certificate. Lovable issues one itself, and a certificate at your registrar is not used by its hosting. The one certificate trap is a CAA record: if the domain has any, they must allow one of the authorities Lovable uses, Let’s Encrypt among them, or setup can stay in Setting up, Stalled or Failed.

No Lovable project found at this address: what the message means

The message “No Lovable project found at this address.” means the lovable.app address you opened has no published project answering at it. The things to check are a mistyped or changed subdomain and a project that was unpublished or deleted. It is not a DNS error on your own domain.

An unused lovable.app address returns a page titled “Project not found” with the single line “No Lovable project found at this address.” and an HTTP 404 status (checked on 21 October 2026).

Our reading is that the cause sits in one of these places, each worth checking in this order:

• The address is not the project’s address. The lovable.app address uses the project’s URL subdomain, which can differ from its display name, and renaming the project does not change the URL.
• The subdomain was changed. Changing it in Project settings → URL subdomain moves the site to the new address.
• The project was unpublished, by someone with publish access or by Lovable after 12 months of inactivity in a Free workspace. After an unpublish, the live URL becomes inaccessible.
• The project was deleted or never published at that address. Deleting a project takes its published app offline within about a minute and frees its URL subdomain for another project to take; the page the old address then shows is not named in Lovable’s docs.

None of this involves your own domain. A custom domain has its own statuses, covered above, and a DNS fault shows there, not on the lovable.app page. If Google is the one showing this message for an old lovable.app address, the Google section below covers which address it keeps.

No working published build found yet

The message in full reads: “No working published build found yet. Publish or update your project to see it here.” No Lovable documentation page mentions the sentence (searched on 21 October 2026), so where it appears is not something Lovable documents. Read literally, it asks you to publish or update your Lovable project so a working build can appear at that address: either nothing has been published yet, or the last publish did not produce a working build. Either way, the next step is the same one as in the six-failure table: open the Publish dialog, publish, and read the banner if one appears.

Google still shows the lovable.app address after the domain went live

Google can keep showing the lovable.app address after a custom domain goes live. The address cannot be removed, Lovable’s redirects between connected domains are temporary 302s, and Google’s documentation says a temporary redirect shows the source page in its results. A canonical tag on every route and Search Console tell Google which host to show.

Lovable’s custom domain page is plain about the redirect: “If a domain is primary, all other connected domains redirect to it using a 302 temporary redirect,” and “Lovable hosting does not support 301 permanent redirects between connected project domains.” Its launch guide says that once the primary domain is Live, the lovable.app address redirects there too; the status code of that redirect is not stated in Lovable’s docs. The lovable.app URL itself stays: “there is no way to remove the xxx.lovable.app project URL from your project.”

On Google’s side, Google’s canonicalization guidance ranks the signals: redirects and rel="canonical" annotations are each “A strong signal”, a sitemap entry is “A weak signal”, and the methods “can stack and thus become more effective when combined.” Google’s redirect page adds that permanent redirects show the new target in results while temporary ones show the source page. That page does not say Google ignores a 302; it says which page a temporary redirect tends to keep in results, so the other signals have to carry the rest.

1. 01 Once your custom domain shows Live, open Project → Settings → Domains, use the three dots menu next to it and click Set as primary.
2. 02 Verify that domain in Google Search Console, which Lovable advises once the domain is Live; its SEO review can do it from the Google Search Console finding.
3. 03 Point every route's canonical URL at that host, publish, and submit the sitemap from the live site on that host.
4. 04 In URL Inspection, inspect one important page on the old lovable.app address and read the Google-selected canonical field.

Lovable’s SEO documentation explains why publishing comes before the sitemap step: “Google reads the sitemap from your live site,” so pages only in unpublished code are left out. The last step is the only proof, and it moves on Google’s schedule: Google says the live test “cannot predict” whether a page will be considered canonical, so read the indexed result.

When it was Lovable and not you

A Lovable publish can fail on Lovable’s side, and the status page’s incident history records publishing and domain incidents. A green status page is not proof: an incident can run with no component marked as affected, so read the history before rebuilding anything.

Lovable’s incident history listed these among its rows touching publishing, published sites or domains in its July to October 2026 window, read on 21 October 2026:

Two of those rows change how you read the page. The 2 October incident lists “No components marked as affected”, so a glance at the component list would not have shown it. The 25 September one was not Lovable’s fault at all: Lovable traced it to “an outage at the .shop domain registry, affecting .shop domains across all providers.” A domain can go dark because of a registry far above your project and above Lovable.

The 15 September row is a reminder that a publish can fail for reasons outside publishing; that incident hit sign-in and account actions, and those affected were told to reload the page to pick up the fix. If the whole product looks down rather than one publish, go back to the check in the first section.

How to keep a Lovable domain from going dark again

A Lovable domain stays up when four things we’d insist on are written down and owned: who controls the registrar account and its renewal, which DNS records the app needs, a check that alerts when the address stops answering, and a copy of the app that can be deployed somewhere else.

Two defaults help with the first row on a domain bought through Lovable: auto-renew is enabled and the transfer lock is on. If a Lovable-bought domain is not renewed, it stops serving traffic and enters a redemption grace period of around 30 days. The last row is the subject of running a Lovable app off Lovable.

We audited 21 third-party apps in June and July 2026, and 17 of them had no error tracking or alerting, so when a user hit an error, nothing recorded it.

Those 21 were apps we chose to audit, a selected set rather than a random sample, so the count describes them, not every app. The point carries over to a domain: one that goes Offline at night is found by a customer unless something outside the app is watching it.

The full set of domain controls, each with a check, sits under HTTPS, HSTS and a locked registrar. How this fits a small team’s way of shipping is part of the release basics a small team needs.

Where the sprint does this

The Production Hardening Sprint keeps the application in a version-controlled repository and on a hosting account the founder controls, deployable through a documented pipeline, independent of the tool that generated it, so a publish problem inside the builder is no longer the only way to ship. Hosting, paid tools and API usage are paid through your accounts. That includes your Lovable plan and your domain renewal. Moving hosting is its own decision with its own build settings; moving a Lovable app to Vercel covers it.

Common questions about Lovable publishing and domains

What happens when I publish a website on Lovable?

Lovable deploys a snapshot of the current version of your project to a live URL, an address ending in lovable.app by default, and hosts it for you with HTTPS included. Later edits do not reach the live site until you publish again with Publish changes, and a connected custom domain serves the site once its status is Live.

How do I Publish my Lovable project?

Click Publish in the top-right corner of the editor, next to Share, check the suggested lovable.app address and the Quick scan line, then click Publish in the dialog. Publishing from the dialog is free and works at a zero credit balance, while asking Lovable to publish in the project chat is treated as standard build usage and consumes credits.

How much does it cost to Publish on Lovable?

Publishing to a lovable.app address is free and available on all plans, and the Publish dialog uses no credits. Connecting a custom domain requires a paid plan, and apps that use the built-in backend or AI features need available credits to serve requests.

When should I stop retrying a Lovable publish and get help?

Stop retrying when the same banner returns after about three tries, when the fix sits in an account nobody on your team can open, or when a domain still shows nothing after the three days Lovable allows for DNS changes, with records that look right. AxonBuild goes over the banner, the domain status and who holds each account with you in a free audit.