When Lovable says Oops! Something went wrong and we couldn't publish your site., do not start by changing DNS or rewriting the app. The publish banner and build details determine the next step.
30-second answer
- Try again: use this for a temporary publishing failure, once, after a short pause.
- Try to fix: use this when Lovable identifies a build or configuration error; review what it changes before publishing again.
- Ask the assistant: use this when the change can affect live data or needs a decision.
- Domain verification message: open the project’s current domain setup and copy the exact records shown there. Do not reuse records from an old tutorial or another project.
Branch 1 — A temporary publish failure
Check the Lovable status page. If a current incident affects builds or publishing, wait. If status is clear and the banner offers Try again, pause briefly and retry once. Repeated clicking does not diagnose the failure and can make the sequence harder to review.
When the retry succeeds, open the published URL in a private window and confirm that the latest change is present.
Branch 2 — The production build failed
If the banner mentions a build failure or exit status 1, open the build details and find the first specific error above the final failure line. A syntax error, missing import, missing package, or environment mismatch needs a different fix.
If the project exposes a terminal, run:
npm run build
Give Lovable the exact first error and ask it to explain the cause before editing. If you use Try to fix, inspect the changed files and preview the app before publishing again. Restore the last working version if the attempted fix creates a second failure.
Branch 3 — The change touches data or an integration
A schema change, expired integration, missing secret, or plan limit can block publishing. Confirm the connected service is active and that the project contains the required variable names. Never paste secret values into a prompt or support post.
If Lovable warns that a database change could affect live data, use the review or assistant branch instead of automatically approving it. Back up important data and confirm the migration scope before publishing.
Branch 4 — A custom domain will not verify
Open Lovable’s current custom-domain screen for this project. Add or replace only the DNS records displayed there. Remove a conflicting old record only after confirming what currently serves that hostname.
DNS providers use different interfaces, and record targets can change. Do not assume that a Cloudflare proxy must always be on or always be off; follow Lovable’s current project instructions and the DNS provider’s current validation message. After saving, return to Lovable and run its verification again.
Verify the publish
A successful banner is only the first check. Confirm:
- the publish status reports success
- the default Lovable URL loads in a private window
- the main interaction works and the browser console has no uncaught error
- if a custom domain is used, it opens with HTTPS and shows the same release
- the latest intended change is visible after a hard reload
If it still does not work
Return to the last version that published successfully. Apply the failed change in smaller pieces until the first breaking step is clear. If the status page is clear and the same publish error persists, send Lovable support the project URL, exact banner text, first build error, and a redacted screenshot. Do not include API keys, authentication cookies, private repository tokens, or customer data.
Beginner summary
Read the button Lovable gives you. Try again is for a temporary failure; Try to fix is for a named build problem; data changes need review. For a custom domain, copy the records shown in your project now instead of following an old screenshot. After publishing, test the live URL in a private window.