Sending someone your app and hearing back that it’s down is a horrible way to find out. You open the link yourself and either it’s genuinely offline or it sits there for fifteen seconds loading something that was instant last week. You haven’t touched it since then, which is usually the clue.
Apps built with Lovable, Bolt and similar tools go offline for a fairly short list of reasons. Here they are in the order I would deal with them.
It is still hosted by the builder
When you publish from an AI builder, the app is served from a subdomain of the platform on infrastructure the platform runs. That’s the quickest possible route to a link you can share, and for a prototype it’s the right answer.
It also means your app stays up only while the platform stays up, your plan stays active, and the company carries on offering the thing you’re relying on. Credits run out, free windows close, and the way publishing works gets reworked in a product update. Any of those can take your app dark without you doing anything, and you’ll usually hear about it from a user rather than from the platform.
Moving onto hosting you pay for directly is the fix, and it’s a big enough job that I’ve written it up separately: how to move your vibe-coded app onto hosting you own. If you do one thing on this page, do that one.
The database went to sleep
Most vibe-coded apps keep their data in a hosted database on a free tier, very often Supabase. Free tiers are generous about what they let you store and strict about what happens when you stop using them. Supabase pauses a free project after a week with no activity, and once it’s paused somebody has to log into the dashboard and restore it by hand. Other providers spin the instance down after a shorter idle period and cold-start it on the next request, which is less dramatic and still means the first visitor of the day waits.
Either way, the app usually doesn’t handle it well, because it was written on the assumption that the database answers immediately. What the user sees is a spinner that never stops or a page of red text.
Two things help. Look at your database provider’s dashboard occasionally, so a paused project or a nearly-full disk is something you spot rather than something you discover. And once the app has real users on it, pay for the tier that stays awake. On Supabase that’s around 25 dollars a month, which isn’t nothing, and it’s a lot cheaper than losing a customer to a database that was having a nap.
Nothing is watching
Most small apps have no idea whether they’re up. There’s no alarm, so the owner finds out from whoever was inconvenienced, which makes every outage as long as the gap between the app breaking and someone bothering to mention it.
An uptime monitor loads your app from outside every few minutes and messages you when it can’t. UptimeRobot and Better Stack both have free tiers that cover a single site at five-minute intervals, which is plenty. Point one at your homepage and at one page that requires a database read, so that you catch the case where the site loads but the data behind it doesn’t.
Error tracking is worth adding after that, for the times when the app is up and quietly failing for one particular user. Sentry’s free tier is fine for a small app. Start with uptime, because everything else you do about reliability depends on knowing when the app is down.
Real traffic found something you never tested
Demonstrating an app to people isn’t the same as ten of them using it at once. The first busy day, or the first upload four times larger than anything you tried, or the first scheduled job that runs while people are on the site, tends to find a corner that was only ever smooth because nobody else was in the room.
You can’t predict all of them in advance, but you can stop guessing when one shows up. If a page has got slow, open the network tab and look at what it’s actually doing before blaming the connection. Slow pages under real use nearly always come back to the database being asked to do far more work than the page needs, usually because the code fetches a list and then makes one more query for every row in it. That’s a well-understood problem with a well-understood fix once you know it’s what you’re looking at.
In order
If you want a running order:
- Get the app off the builder’s platform and onto hosting you control.
- Move the database onto a plan that doesn’t pause.
- Put an uptime monitor on it today, before either of the above.
- When something gets slow, find out what the app was really doing rather than waiting to see if it happens again.
None of the four shows up in a demo, which is why they tend to go undone until the first outage makes the case for them.
