Supabase paused my project and my app stopped working. Is my data gone?

You open the app and nothing loads. No error worth reading, just a page that never fills in. You log into Supabase and there it is in plain language: the project is paused.

The first thing to say, because it is the thing everybody wants to know and the answer is good: your data is fine. Paused means the compute stopped. The database is still there, exactly as you left it, and restoring it is a button.

The second thing is less comfortable, which is why this article is longer than one paragraph. If your project could be paused without you knowing, several other things about how it is set up are probably also true, and they are worth finding out now rather than during the next outage.

What paused actually means

Supabase pauses free projects after a stretch of low activity. The compute instance is shut down; the stored data is retained. Nothing is lost, and the project can be brought back from the dashboard.

What stops working while it is paused is everything that talks to it: the database, authentication, storage, edge functions. So from your customers' point of view the app is simply broken, with no explanation, and it will stay broken until somebody logs into an account they may not have thought about in months.

How you know this is what happened to you: the app fails to load data but the site itself still serves. The front end is on a different service and is perfectly healthy. It is talking to a backend that has gone to sleep.

Why it happened even though your app has users

Here is where I have to be careful with you, because there is something in the public record I cannot fully explain.

Through late July and early August 2026 a noticeable cluster of people reported free projects being paused despite having genuine, ongoing traffic. One described several hundred API requests a day, every day, for months, and still receiving inactivity warnings and then a pause. Others reported the same shape of experience. In the same fortnight, at least three separate small tools appeared whose only purpose was to keep free projects from sleeping — which is a reliable signal that a lot of people were hitting this at once.

What I cannot tell you is exactly what Supabase counts as activity for this purpose, because it is not documented in a way that resolves the question, and I am not going to invent a mechanism to make the article tidier. The honest version is: ordinary API traffic through the gateway does not appear to be sufficient on its own to keep a project marked active. That is an inference from a consistent pattern of reports, not a documented rule, and you should treat it as such.

The practical consequence is the same either way. If your production backend is on a free project, do not assume that having users protects it.

The restore window, and why I am hedging

Supabase's documentation on this page currently describes pausing after low activity over a seven-day period, and a restore window of up to a year. An earlier heading on that same page described ninety days.

I could not establish when it changed or which applies to a project paused today, and I would rather tell you that than pick the number that reads better.

So plan for the shorter one. If a project is paused, restore it now rather than at the weekend. The cost of acting as though you have three months when you have a year is nothing at all. The cost of the reverse is a database.

Why this hits AI-built apps harder than most

There is nothing special about an AI-built app from Supabase's point of view. What is different is the circumstances around it, and they stack up in an unhelpful direction.

Nobody chose the free tier. It was the default when the tool created the project. There was no moment where somebody weighed the tradeoffs, so there was no moment where anybody registered that this backend has no backups and goes to sleep.

The account is often not yours. If an agency, a freelancer or a friend set it up, the project sits under their login and the warning emails go to them. I have seen apps paused for a fortnight because the notification was sitting unread in the inbox of somebody who finished the job in March.

The warnings are quiet by design. They are emails from a developer platform, and they arrive in the same stream as changelogs and product announcements, which means they are filtered out by exactly the habit that keeps a founder's inbox usable.

And there is usually more than one project. A development project, a staging project someone made once, and the real one — created in that order, named unhelpfully, and by the time it matters nobody is certain which is which.

What to do right now, in order

Restore it. Dashboard, project, restore. It takes a few minutes to come back up.

Then immediately take a copy of the data. This is the step people skip, and it is the most important one on the page. You have just been reminded that this database has exactly one copy of itself and it lives on a free plan. Take a dump now, while you are thinking about it and while the project is awake.

Then work out which project this actually is, and rename everything so the next person can tell. Production, staging, scratch. Five minutes, saves an hour at the worst possible time.

Then check the email on the account and make sure it reaches somebody who will act.

The four options, honestly ranked

Upgrade the production project to a paid tier. Twenty-five dollars a month, and it is the right answer for anything with customers on it — not principally because it stops pausing but because it comes with daily backups. If people are paying you money for something and it has no backups, the pausing is the second most urgent thing you learned today.

Pause the ones you are not using, deliberately. Development and staging projects should sleep. The problem was never that projects pause; it was that the wrong one paused without anyone deciding. Take a dump first, then pause on purpose.

Keep-alive pings. They work, largely, and the tools people built for this in mid-2026 do the job. I will not pretend it is a solution: you are keeping one free service awake by depending on another free service, and given the reports of projects pausing with real traffic, the mechanism you are gaming may not be the one you think it is. Fine for a hobby project. Not something I would put a customer-facing product behind.

Move somewhere else. Legitimate, and it is a standard Postgres database so the export is unremarkable. But be clear about why. If the reason is money, a paid project costs less than the hours the migration will take. If the reason is that you want your data somewhere you control outright, that is a good reason and a different article.

The thing this is really telling you

A pause is a cheap lesson wearing an expensive costume. Nothing was lost, everything came back, and in exchange you found out four things about your setup that were true all along: it had no backups, its notifications went to the wrong person, nobody could say for certain which project was production, and the plan it ran on had been chosen by a tool rather than by you.

Every one of those is worth twenty minutes today. None of them will be worth twenty minutes when they matter.

The fix: write down, in one place, which services your app depends on, whose account each one is under, which plan it is on, where the notifications go, and where the backups are. Most people building this way have never had that list. It takes an afternoon to make and it is the single highest-value document in a small software business.

If you want somebody to do that pass with you

If the pause has made you realise you do not actually know what your app is standing on — which services, whose accounts, what happens if any one of them goes quiet — that is a bounded piece of work rather than a hire.

I do a Production-Ready Audit that includes exactly this: every service the app depends on identified with its plan and its owner, backups verified by actually restoring one rather than confirming that a setting is switched on, the notification paths checked, and a written list of what to fix in priority order. From $499, back in five to seven days.

You are also welcome to just send me a list of the services you think your app uses. I will tell you what is usually missing from a list like that, at no charge and with nothing attached.

The deployment and reliability side of this work is on the launch and deployment page. If your app is down right now and you are not sure a paused database is the cause, work through my app is down and I do not know why first. The Lovable version of the same class of problem — a live backend going dark for a billing reason rather than a technical one — is in your Lovable app went down because you ran out of credits. And for what these services actually cost once you stop relying on free tiers, there is what it costs to take an AI prototype to production.