My live Lovable app stopped working and it says I am out of credits. Why does that take my app offline?

There is a particular kind of panic that comes from an outage with no error in it. The app is down, customers are emailing, and the only message anywhere is about a credit balance — which sounds like a billing matter, not an outage, and so the first ten minutes go into wondering whether the two things are even related.

They are. Since the middle of June 2026 they are the same thing.

What changed

On 18 June 2026 Lovable merged what used to be separate balances into one. Before that, the credits you spent asking the assistant to build things and the cost of running your published app's backend were tracked apart. Running low on one did not touch the other.

Now there is a single balance, and three quite different things draw from it: the messages you send while building, the compute your deployed backend uses, and any AI features running inside your live app for your customers.

That is a defensible design and it makes the true cost of a project visible in one number, which is arguably an improvement. The consequence, though, is one most people would not guess: your production backend is now governed by an AI credit balance.

The part that catches everyone: the database is rented, not metered

If you assume credits are consumed when something happens — a visitor arrives, a query runs, a message is sent — the arithmetic will not make sense to you, and this is where most of the confusion comes from.

Backend compute is billed as capacity that is running, not as work that was done. The instance is up, therefore it costs, whether or not anybody visits. An app with zero users and zero traffic still draws credits every single day for as long as it exists.

Users who worked this out and posted their figures in the weeks after the change reported something on the order of one and a half to two and a half credits a day for a small instance, against a free monthly grant of twenty. Do that arithmetic and a dormant project exhausts a free allowance in under a fortnight while doing nothing at all. One person tracking their first twenty-four hours on the new system found roughly ninety-five per cent of their consumption was the database rather than anything they had asked for.

This is why the projects that go dark are so often the ones nobody was looking at — the demo built for a client, the internal tool, the version two that was parked. They were not costing you attention, so it did not occur to anyone that they were costing you anything else.

What actually happens when you hit zero

Three things, and the third is the one to plan around.

AI features inside your deployed app stop. If your product does anything with a model for your customers, that is the first thing to break, and to your users it looks like a broken feature rather than a billing state.

Backend services pause. Not the editor. The backend of the published application — database, authentication, storage, functions. Which means the app your customers use is now a front end talking to nothing.

And you cannot get your data out while it is paused. Lovable's own documentation says this directly: while services are paused your data remains safe, and you can neither access nor export it until they are running again.

Read that third one twice, because it is the whole reason this article exists. The moment your app goes down is also the moment the exit is locked. Not permanently — topping up reopens both — but if the reason you have run out of credits is that you did not want to spend any more money on this platform, you have arrived at a place where leaving requires you to spend money on this platform first.

The fix, in one line: never let the balance be the thing that decides. Export while everything is healthy and you have no particular reason to.

The scheduled job that is probably draining you

This is the most useful thing in this article and it takes one query to check.

When Lovable sets up email for a project, it creates a scheduled job in your database that processes an email queue. The schedule it writes is every five seconds — around seventeen thousand invocations a day, running against a queue that is empty almost every time.

The effect is not the compute of the job itself, which is trivial. The effect is that the database never gets to be idle, so it is never anything other than fully awake and fully billed. One user who traced their consumption found a project burning more than ten times what a comparable production project was using, and it was this.

To check, open the SQL editor inside Lovable and run:

SELECT jobname, schedule FROM cron.job;

If you see a five-second schedule on an email queue job, that is it. Widen it to something sane — once a minute is generous for a queue that is usually empty — and watch the daily consumption fall.

One catch worth knowing: re-running the email setup recreates the job at its original schedule. So if you rotate a key, change your sending domain, or ask the assistant to fix something about email, check the schedule again afterwards. This is not a fix you make once.

What to do this week, in order

One, run that query. Five minutes, and for a lot of people it is most of the problem.

Two, pause anything dormant. Lovable added a pause control in July 2026 that stops compute credits accruing on a project you are not working on. Every parked demo, every abandoned experiment, every client project that finished — pause them. This is free money.

Three, right-size the instance. The database size can be changed, and most projects are running something larger than the traffic justifies because nobody chose it deliberately.

Four, take an export now, while everything is fine. Not because you are leaving. Because an export you already have is worth more than one you are entitled to.

Five, decide about the platform deliberately — with the app running, not while it is down.

Take the export properly, because it is narrower than it sounds

The export shipped in July 2026 and it is a real database dump, which is a meaningful improvement on what existed before. But it has edges, and finding them during an emergency is the wrong time.

It is capped at five gigabytes. You get one per project per twenty-four hours. And it contains the database — not the files in your storage buckets, not the code of your edge functions, and not your secrets. Those are three separate things you have to collect by hand, and the secrets in particular cannot be read back out of the interface, so if the only copy of an API key is in Lovable's settings, it exists nowhere.

Password hashes are the other gap. An export will not give you something you can drop into another system and have everybody's existing passwords still work, so any migration plan needs a password reset flow in it. I have written about that in more detail in moving from Lovable Cloud to your own Supabase.

The order-of-operations trap: removing Cloud from a project is permanent, and once it is removed you can no longer download exports. So the sequence is export, download, verify you can open the file, and only then remove. Doing those in any other order is how people lose things.

Is this a reason to leave?

Honestly, it depends on what the app is, and I would rather give you the real answer than the one that sells more work.

If it is a prototype, a demo, or an internal tool with a handful of users, the sensible move is almost certainly to fix the scheduled job, pause it when not in use, and carry on. Migrating a project like that costs more than several years of credits.

If it has paying customers, the calculation changes, and not mainly because of cost. The reason to own your database directly is that it gives you a dashboard, a connection string, your own backups and your own billing relationship — which means that the question "is my product running" stops being coupled to a credit balance at all. That is worth doing calmly, over a couple of weeks, at a moment of your choosing.

If you are somewhere in between, the honest middle path is to stay where you are and make the exit real: take the export, collect the storage files, copy the function code into a repository, and write the secrets down somewhere safe. Then the decision stays open, which is the position you actually want to be in.

If your app is down right now

Top up enough to bring the backend back, then work through the list above in order. Do not make the migration decision tonight. Almost every expensive rebuild I have been asked to quote for started with somebody making a structural decision during an outage.

If what you want is for somebody to look at the whole picture once and tell you plainly what this project costs, what is draining it and whether it should move, that is a defined piece of work.

I do a Production-Ready Audit that covers this ground: what the app is actually spending and on what, the scheduled jobs and background work nobody knew about, whether the export you hold is complete, and a written recommendation on staying or moving with the real cost of each. From $499, back in five to seven days.

You can also just send me a screenshot of your usage page and the output of that cron query. I will tell you what is eating it, at no charge and with nothing attached.

The migration and repair work is described on the AI SaaS rescue page. For what running an app like this actually costs across every service, there is what it costs to take an AI prototype to production. And if the deeper worry underneath this is what happens if the platform decides something about your account rather than your balance, that is locked out of your own app.