Lovable
Lovable app down
“Down” is three different failures: the published host does not answer, the custom domain does not point at it, or the host answers 200 while the route a customer needs returns an error.
Symptoms
- The preview opens. The published URL 404s or times out.
- The lovable.app host works and the custom domain does not.
- The homepage returns 200 and the checkout or signup route returns 500.
- It works for you, logged into Lovable, and not in a private window.
Common causes
The project was edited and not published
The preview tracks the latest generation. The public URL stays on the last publish. You are testing two versions and only one of them has the route.
The custom domain is only half connected
DNS has not moved, or it moved and the certificate is not ready. The default host still works. The domain on the ad does not.
An env var exists on the preview only
The published function throws when it reads the Stripe key or the Supabase URL. The homepage, which does not call that function, stays green.
A server function times out
The route starts and never returns. The browser shows a generic failure. The preview, doing less work or using cached state, still feels fine.
You are looking at an authenticated preview
The editor session can see a draft the public internet cannot. A private window on the published URL is the version customers get.
Fix it
Compare three URLs
Open the preview, the published *.lovable.app host, and the custom domain, in a private window. Whichever one fails is the one to fix. Do not debug the preview if the ad points at the domain.
Publish, then recheck
If the preview has the route and the public host does not, publish. Check the public host again after it finishes, not the preview tab you already had open.
Read the function log for the failing route
A 500 on /checkout with a missing env var is not downtime. Add the variable to the published environment and publish again.
Check DNS and the certificate
The domain should point where Lovable told you, and HTTPS should open without a warning. The free website checker on this site reports status, response time, and certificate expiry for a public URL.
Request the customer route, not only /
A monitor on the homepage will stay up through a checkout 500. Add the URL that is actually failing, or map the funnel.
Catch it automatically
Put the published URL on a free five-minute check, and put the checkout or signup on a funnel once you verify the domain. The ping catches a host that stopped answering. The replay catches a publish that left the homepage up and the button dead.
Watch the next break before a customer does.
Map the path once. The next publish does not get to fail in private.
Questions
The preview works. Is the app up?
The preview is up. Customers use the published URL or the custom domain. Check that one in a private window.
The homepage is 200 and people say it is down.
Ask which URL they opened. Then request that path. A 500 on a route is a broken app with a healthy homepage.
How often should I check?
The free plan fetches every five minutes. A funnel replay on Pro runs hourly, on demand, or from a deploy webhook after you publish.