Nothing ruins a morning like a message saying “your app is down”. You click the link yourself and either it’s properly dead, or it sits there loading for fifteen seconds when last week it was instant. And you haven’t touched it. That’s usually the clue.
The good news is that apps built with Lovable, Bolt and friends go offline for a pretty short list of reasons. Here they are, in the order I’d deal with them.
It’s still living on the builder’s servers
When you hit publish in Lovable, your app is served from a Lovable subdomain, on Lovable’s infrastructure. That’s brilliant for getting a link you can send to your mum. For a prototype, it’s exactly right.
The catch is that your app stays up for as long as the platform stays up, your plan stays paid, and the company keeps offering the thing you’re relying on. Credits run out. Free tiers close. Publishing gets reworked in a product update. Any of those can take your app offline without you doing a thing, and you’ll usually hear about it from a user rather than from the platform.
The fix is moving onto hosting you pay for directly. 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 only do one thing on this page, do that one.
The database has nodded off
Most vibe-coded apps keep their data in a hosted database on a free tier, very often Supabase. Free tiers are generous about what you can 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 in and restore it by hand. Other providers spin the database down after a shorter idle period and start it up again on the next request, which is less dramatic, but still means the first visitor of the day gets to wait.
Either way, the app usually doesn’t cope well, because it was written assuming the database answers straight away. What your user sees is a spinner that never stops, or a page of red text.
Two things help. Have a look at your database provider’s dashboard now and then, so a paused project or a nearly-full disk is something you spot rather than something you discover. And once you’ve got real users, pay for the tier that stays awake. On Supabase that’s about 25 dollars a month, which isn’t nothing, but it’s a lot cheaper than losing a customer to a database that was having a nap 😴.
Nobody’s watching
Most small apps have no idea whether they’re up. There’s no alarm. So the owner finds out from whoever got annoyed, which means every outage lasts exactly as long as it takes for someone to bother mentioning it.
An uptime monitor loads your app from the outside every few minutes and messages you when it can’t. UptimeRobot and Better Stack both have free tiers that check one site every five minutes, which is plenty. Point it at your homepage and at one page that needs the database, so 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 but quietly failing for one particular person. Sentry’s free tier is fine for a small app. But start with uptime. Everything else you do about reliability depends on knowing when you’re down.
Real people found something you never tested
Showing your app to people one at a time isn’t the same as ten of them using it at once. The first busy day, the first upload four times bigger than anything you tried, the first scheduled job that runs while people are on the site… these tend to find the corner that was only ever smooth because nobody else was in the room.
You can’t predict them all, but you can stop guessing when one turns up. If a page has got slow, open the network tab in your browser and look at what it’s actually doing before you blame the wifi. 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. Once you know that’s what you’re looking at, it’s a well-understood problem with a well-understood fix.
The running order
- Put an uptime monitor on it today. It takes ten minutes and it’s free.
- Get the app off the builder’s platform and onto hosting you control.
- Move the database onto a plan that doesn’t pause.
- When something gets slow, find out what the app was really doing rather than waiting to see if it happens again.
