Lovable Publish Not Working: The Six Failures, and the Domain That Points Nowhere

You pressed Publish, and the address you gave people shows nothing. Two completely different failures look the same from there: the deploy never finished, or the deploy finished perfectly and the domain you bought has not come up yet. They live on different screens inside Lovable and their fixes have nothing in common.

A Lovable publish that will not work is two failures wearing one face. Check whether the publish finished before you touch DNS. Lovable names six ways a publish fails and eleven states for a domain you connected from another provider, and the repair is different in every one of them.

Every failure name, status name, button label and waiting time below was copied off Lovable’s own publish page, its custom-domain page and its public incident history on 25 August 2026. The sentences are quoted so you can hold them against what your own screen says. No domain was connected and no publish was run to produce any of it.

If you have never published this project at all, the sequence for getting a first version onto an address is written out step by step elsewhere. This page starts at the moment you pressed the button and something did not happen.

Which of the two things went wrong

Start with the publish dialog, not with your registrar. The dialog is the only screen that knows whether a deploy completed, and it says so in plain words either way.

Two neighbouring failures send people to this search and are worth ruling out first. A preview pane that will not load inside the editor and a publish that will not finish break at different moments and leave different evidence behind. And a project that never reached the Publish dialog at all is a build that is still sitting there rather than a publish that failed, which is a hang in the chat panel.

The six ways Lovable says a publish fails

A failed publish is not silent. Lovable puts a Publishing failed banner in the dialog, writes a line explaining what went wrong, and offers one action. As of 25 August 2026 its publish documentation sorts those lines into six named failures, each in its own collapsed section at the bottom of the page. The useful column below is the last one.

Read the banner as a sorting device rather than as a diagnosis. The reason it so often says less than you want is written into the product: “Publish failure messages never include raw logs or output from connected services, so secrets and connection details stay out of the UI. Build errors and conflicting database changes are the exceptions: the banner shows a summary of the build failure or the database’s own error message so you can act on it.” A thin message is the normal case, and the two times the banner hands you something concrete are the two times it has something safe to hand over.

Slow down on the fourth row, because it is the only failure where nothing inside Lovable will move it. The connection is expired, or the other service is at its plan ceiling, and the builder can see the wall without being able to climb it. That usually means opening an account you may not have set up yourself and repairing the settings that live outside your code before you press anything else. If more than one join is misbehaving at once, a connected service that stopped working has its own diagnosis across Supabase, Stripe, GitHub and the rest. One person on another builder wrote:

Anyone else have issues where you CAN’T CHANGE YOUR PUBLISHING SECRETS?!?! They are kind of important, and until I can update them and not have them revert to their old values by themselves I’m stuck with a non functioning app.

The speaker was on Replit rather than Lovable, and the bug they hit is a different one. It is quoted here for the shape of the problem: when the blocked thing is a credential the builder holds on your behalf, the publish button stops being where the work is.

The fifth row scares people more than it should. A database conflict means the publish carries a schema change the live data will not accept, and Lovable’s documented action is Ask the assistant to help. The sentence that matters sits under it: because the fix affects real data, Lovable confirms with you before changing anything. You are not one click from rewriting the orders table by accident.

Not every wall is one of the six. Publish blockers also come from the account rather than the project, and the failure then arrives without a banner at all. One Lovable user described what that looked like:

when there was 3 days till my subscription renews, I didn’t buy extra credit… they freezed my server and even login in preview was not working. This is the moment I realized not ant more.

The ellipsis and the typo are theirs. A workspace paused because it ran out of credits is a billing event with its own sequence, and no number of retries in the Publish dialog will resolve one.

Why is the Publish button greyed out?

A greyed-out Publish button in Lovable has two common causes, and Lovable names both. Either your role sits below editor access, which the button tells you when you hover it, or a workspace admin turned on a setting that blocks publishing while error-level findings are open. Both of those sit with somebody else’s account settings rather than with your app.

The first reads You don't have permission to publish this project on hover. Lovable’s documentation says publishing needs editor access or above, and that on Enterprise plans workspace admins and owners can restrict it further. If you built the project inside somebody else’s workspace, this is the likeliest answer, and it is fixed by the person who owns the workspace rather than by anything you type.

The second is a switch named Block publishing with critical findings, which a workspace admin or owner turns on at Settings → Security → Privacy & security. With it on, the documentation says it prevents publishing while error-level findings are unresolved. Open the Security view, clear those findings, and the button comes back. The switch is a workspace policy somebody chose, so its presence tells you nothing about the state of your app.

The publish worked and the domain still shows nothing

This is the other half of the search, and it has its own vocabulary. Lovable gives a domain bought outside Lovable a status, shows it in the project’s domain settings, and documents the user action for each state. As of 25 August 2026 its custom domain documentation lists eleven, ten of them for the connected domain and one, Unpublished, shown only for the lovable.app project URL.

Two of those eleven answer questions people ask constantly without knowing there is a status for them.

Ready catches the people who did everything right. The records are correct, the certificate exists, the domain is waiting, and the address returns nothing because the project behind it is unpublished. Lovable’s fix is one line long: publish the project, and the status turns itself to Live. If the domain is attached to a project you have not published since, this is your answer and it costs one click.

Offline is the one nobody documents anywhere else. It is the state for a domain that worked and then stopped, and Lovable’s description names the cause outright: the records are no longer valid, so the domain is no longer pointing at your project. Somebody changed DNS, often through a registrar migration, a new email setup that rewrote a record set, or a tidy-up at the provider. The Recover button shows the records Lovable expects, which is the fastest way to see what your DNS used to say and what it says now.

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

Lovable’s own table draws the line at one hour and at 72 hours in the same row. Unable to verify appears when DNS verification has not completed within an hour, and the note directly under it says propagation can run to 72 hours. Recheck the records at one hour. Start calling it broken at 72.

Both halves are Lovable’s words. The status reads “DNS verification did not complete within one hour. This usually means your DNS records are incorrect or still propagating.” The note attached to the same row reads “DNS propagation can take up to 72 hours, although most updates are applied within a few hours.”

The warning fires after one hour. The vendor’s own outer limit is 72. So a red status at hour two is a prompt to check your typing, not proof that you made a mistake.

The gap explains why advice about waiting is so contradictory. A DNS record carries a time to live, defined in RFC 1035 from November 1987 as “a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded”. Every resolver between your visitor and your domain is allowed to hold the old answer until that clock runs out. Nobody flips a switch worldwide, so “propagation” is really thousands of separate caches expiring at their own pace.

The part that traps people is that a failed lookup is cached too. RFC 2308, “Negative Caching of DNS Queries”, published in March 1998, says a negative answer gets its own time to live, taken “from the minimum of the SOA.MINIMUM field and SOA’s TTL”, and that until the clock reaches zero the cached negative answer stands. So if you looked at your domain in the first ten minutes, before the records were right, your own machine may be sitting on a remembered “this does not exist” that has nothing to do with your current settings. That is why waiting works, and why Lovable’s own troubleshooting list puts removing and re-adding the domain last, after the record checks and a cache clear: re-adding restarts the setup, and the stale answer in front of you expires on its own schedule either way.

There is a public example of how expensive that misreading gets. On the Let’s Encrypt community forum, on 7 August 2025, the owner of a Lovable-hosted site posted that the bare domain worked while the www address failed. A responder reproduced it: curl against the apex returned HTTP/2 200, and the same tool against www returned curl: (35) error:0A000410:SSL routines::sslv3 alert handshake failure. The same responder checked the certificate record and wrote, “You have gotten more than 15 certificates covering those two domain names in about the past week. You definitely do not have a problem getting certs”. A week of retrying had produced more than fifteen certificates and no working site. The owner’s own closing note names the cause: they had started changing things roughly 48 hours in, “we set it back to what Lovable wanted and ..24 hours later.. we are up and running normally.”

So the working rule is a short one. Check your records once at the one-hour mark, leave them alone, expect a few hours, and treat 72 as the point where the wait itself has become the evidence.

The four domain traps Lovable documents and most guides skip

These four have nothing in common except the result: a domain that looks connected and serves nothing. All four are written down on Lovable’s own custom-domain page.

The www address you assumed came free. For a domain bought through Lovable, the root and the www subdomain are set up together and listed separately. For a domain bought anywhere else, the documentation is explicit that the www subdomain is not included when you set up your domain, that you need to add it separately, and that it will be listed separately. Plenty of visitors type www out of habit. If you connected only the root, every one of them gets nothing.

An AAAA record quietly steering traffic elsewhere. Lovable’s prerequisites ask that there are no AAAA records set for the domain you are connecting, because an AAAA record can interfere with domain setup and cause traffic to be routed incorrectly. Its troubleshooting section repeats the point for a domain showing the wrong site or an outdated version: check for AAAA records, remove them, and retry the connection once the change has propagated. An IPv6 address left behind by a previous host will happily answer for you.

Cloudflare set to Proxied instead of DNS only. If your DNS is at Cloudflare and the domain shows a Cloudflare error 1001 or 1003, Lovable’s answer is that these come from Cloudflare’s proxy rather than from Lovable, and that the fix is to set the records for your Lovable domain to DNS only (gray cloud) instead of Proxied (orange cloud), then wait a few minutes and try again.

Records left over from the site you had before. For a domain showing your old website, Lovable says your DNS provider probably still has A, AAAA, or CNAME records left over from your previous website or hosting provider. The repair is to remove the old web-hosting records (A, AAAA, CNAME) for the host you are connecting so that Lovable’s own A record and its verification TXT record are the ones answering for it, leaving mail (MX, SPF) and unrelated verification TXT records alone, then wait for propagation. The exact records each builder asks you to paste are listed elsewhere and are worth copying rather than typing.

One rule sits above all four, and it is the one a worried person breaks first. Lovable provides the exact DNS records required for verification, and says those records must remain unchanged until verification is complete. While verification runs, its documentation says not to enable proxying on the A record and not to point that record at a CDN or reverse proxy. If either happens, the domain stays in Verifying. So the instinct to start editing at minute forty is the thing most likely to keep you stuck at hour six.

When it was Lovable and not you

Lovable publishes a public incident history, and the publish path shows up in it often enough to be worth checking before you rebuild anything. Between 22 June and 21 July 2026 it recorded five separate publish or domain incidents. The window rolls, so this is what the page held on 25 August 2026.

Read the 22 June row twice. The panel was not showing the published URL, and Lovable’s own investigating note says the site was live and accessible throughout. A publish panel that tells you nothing is a different event from a publish that failed, and on that Monday anyone who rebuilt their DNS in response was repairing something that already worked.

The 21 July row is the other useful one, for the opposite reason. No component was marked as affected, so the status page carried no red for an incident that was stopping publishes. A green status page is evidence that nothing has been filed, which is not the same as evidence that nothing is wrong. On Lovable’s status page the hosting side is reported as its own group, separate from the editor, so the grouping is worth a glance even when nothing on it is red. Reading the status pages of five builders at once, Lovable and Base44 and Replit and Bolt and v0 together, is the wider is-anything-down question.

The 29 June row is the one to check if your domain already worked. Lovable said sites on active custom domains were unaffected throughout, so an incident about new domain setup is not an explanation for a domain that went dark on you.

When to stop retrying and get somebody to read it

Retrying is the right first move and a bad third one. Four signals say the loop has stopped paying.

The same failure type comes back after three presses of Try again. Temporary means temporary. A repeated external connection or secret or configuration issue banner is a standing condition rather than a blip.

Your banner names a connection outside the project and you have no access to that account. No amount of prompting inside Lovable moves an account you cannot open.

The domain has been past 72 hours with records you believe are correct. At that point either the records disagree with what Lovable is expecting or a certificate never issued, and both need somebody comparing what is published in DNS against what the project asks for.

Publishing succeeds and the live site is a version you do not recognise. Something is deploying, and finding out what is worth doing before the next attempt buries the evidence.

One competitor page ranks for the domain half of this search. Afterbuild Labs, at afterbuildlabs.com, sells a $299 emergency triage with a 48-hour turnaround and a launch package from $1,999, and its Lovable custom-domain page is genuinely good on DNS, certificates and registrar steps. Prices checked 25 August 2026. It covers the domain half only, which is why the first table on this page exists.

Moving the app onto Vercel’s hosting instead is a hosting change with its own build settings, and it is the wrong answer to a publish that failed once. What Lovable’s own hosting is and is not built for is the question underneath it. And two failures that arrive at this search belong elsewhere: a site that serves fine at its address and cannot be found in Google is an indexing problem rather than a publishing one, and a store build that crashes on somebody’s real phone after you shipped it starts in the binary you uploaded rather than in the publish step. A build that sits in a queue and never starts, on Vercel or anywhere else with a queue, fails a step earlier than anything on this page.

Common questions about a Lovable publish that will not work

Why does my Lovable publish keep failing?

Because one of six named conditions keeps recurring, and Lovable’s banner tells you which. A repeated temporary issue points at a connected service that is rate limiting you. A repeated error in your app means the build genuinely fails and Try to fix has not solved the underlying cause. A repeated external connection or secret means an expired connection or a plan ceiling somewhere outside the project, which Lovable states it cannot change for you. Read the banner text before pressing anything, because the six have almost nothing in common.

Why is my Lovable custom domain not working?

Check the domain’s status in the project’s domain settings first. A domain you connected from another provider gets eleven of them, each with its own documented action, and a domain you bought through Lovable gets four instead: Pending, Live, Ready and Removed. Verifying and Unable to verify mean DNS has not been confirmed. Stalled and Failed mean the certificate did not issue. Ready means everything is correct and the project is unpublished. Offline means it worked and the records changed. Guessing without the status name is what turns a one-hour wait into a week.

How long does a Lovable custom domain take to go live?

Most changes apply within a few hours. Lovable’s documentation says propagation can take up to 72 hours, although most updates are applied within a few hours, and its own status table raises Unable to verify if DNS verification has not completed within one hour. Treat the one-hour flag as a prompt to recheck what you typed, and 72 hours as the point where waiting longer has stopped being reasonable.

Was it a Lovable publish incident and not my project?

Check Lovable’s status page and its incident history before assuming it. Between 22 June and 21 July 2026 the history recorded five separate publish or domain incidents, so it does happen. The one caution is that on 21 July no component was marked as affected while publishes were failing, so a page with no red on it is not proof. Triage across several builders at once is a wider question with its own answer.

Why does my domain show my old website?

Because the old records are still there. Lovable’s answer is that your DNS provider probably still has A, AAAA, or CNAME records left over from your previous website or hosting provider. Remove the old web-hosting records (A, AAAA, CNAME) for the host you are connecting, leave Lovable’s own A record and its verification TXT record in place along with any mail or unrelated verification records, and wait for propagation. Your browser may hold the old answer for a while after DNS is correct, so check in a private window.

Do I need to buy an SSL certificate for my Lovable domain?

No. Lovable states that when you connect a custom domain it automatically generates and installs an SSL certificate for it, and that if the certificate has not been issued after 72 hours you should contact Lovable Support. A certificate you buy at your registrar is not used by Lovable’s hosting, so buying one adds cost without changing anything on the site.

Why is my published Lovable site showing an old version?

Because publishing deploys a snapshot, and later edits do not go live on their own. Publish again, then load the public address in a fresh private window. The tab you have been working in may still be serving you the previous version from cache.

Can I connect a domain before I publish?

Yes, and the status table has a name for exactly that situation. A domain that is set up correctly against an unpublished project sits at Ready, and Lovable says that when the project is published again the status automatically becomes Live. So a domain showing nothing on a project you have never published is behaving correctly, and the missing step is the publish rather than the DNS.

Does removing and re-adding the domain fix it?

Sometimes, and Lovable’s own troubleshooting list does name it, as the last of four steps for a domain that is connected but never becomes live: check the records with a DNS lookup tool, confirm the records Lovable expects at Project → Settings → Domains, clear your browser cache or open an incognito window, and then “Try removing and re-adding the domain in Project → Settings → Domains.” Its 7 July 2026 certificate incident note said the same, that if a domain still was not active, removing and re-adding it would retry the process. The narrower rule still holds: a Stalled certificate does not need it, because Lovable states there that you do not need to remove and re-add the domain and Retry is the documented action. So work down that list in order rather than starting at the bottom of it.