Why your Supabase project paused itself, and how to stop it happening in production

You opened your app and it’s throwing database errors. You log into Supabase and there’s a banner: your project is paused. Nothing’s broken, you didn’t do anything wrong, but your users are staring at a dead app. Here’s exactly why free-tier projects pause, how to un-pause yours right now, and how to make sure a production app never ends up here.

Why this happens

Supabase pauses free-tier projects after a period of inactivity. If a project gets no requests for about 7 days, Supabase stops the database to save resources. It’s a documented part of the free plan, not a bug and not an outage on their side.

The catch is what counts as “activity.” It’s traffic to your database, not you having the dashboard open. A side project that nobody visits for a week goes quiet, and Supabase reads that quiet as “nobody needs this,” so it pauses. The database isn’t deleted, it’s stopped. Your data is still there. But every query fails until you resume it.

This trips up two kinds of people especially:

The launcher. You build something, it’s not live yet, you take a week off. You come back to a paused project and think you lost everything. You didn’t, but the panic is real.

The low-traffic founder. Your app is live but quiet. A few days with no visitors and it pauses itself, which means the next visitor, maybe your first real customer, hits a broken app. The pause causes exactly the downtime you were trying to avoid.

The free tier also limits how many projects you can keep active, which is why some people find an older project paused while they were working on a newer one.

How to fix it

Right now: resume the paused project.

Log into the Supabase dashboard, open the paused project, and click Restore or Resume. It takes a few minutes to spin the database back up. Your data comes back with it, because a pause is a stop, not a delete.

While you’re there, grab a backup so you’re not relying on the platform’s state. From your own machine:

pg_dump "postgresql://postgres:[PASSWORD]@db.[PROJECT_REF].supabase.co:5432/postgres" \
	--format=custom --file=supabase-backup.dump

Keep that file somewhere safe. Now you have a copy that no pause, plan change, or dashboard mistake can touch.

Short-term: stop the pause on the free tier.

The pause is driven by inactivity, so real activity prevents it. The clean way is an uptime check that pings a lightweight endpoint every few minutes. That traffic keeps the project counted as active, and as a bonus it tells you the moment your app goes down. A simple health route that touches the database:

// GET /health
app.get("/health", async (req, res) => {
	await db.query("SELECT 1");
	res.json({ ok: true });
});

Point an uptime monitor at /health on a 5-minute interval. Don’t fake activity with a pointless loop that burns your row and bandwidth limits. A single cheap query is enough.

Be honest with yourself about what this is, though. Keeping a free project awake with a monitor is a workaround, not a production setup. It papers over the pause without fixing the underlying fact that a free tier can pause, throttle, or change under you.

Real fix: don’t run production on a plan that pauses.

If people rely on your app, the pause behavior alone is a reason to move up. The two clean paths:

1. Upgrade Supabase to a paid plan. Paid projects don’t pause for inactivity. This is the least-effort fix if you’re happy staying on Supabase.
2. Move to a database that was never going to pause on you. Your own managed Postgres, running independently of your app, with real backups and no inactivity rules. More setup, more control, and no surprise banners.

Either way, the goal is the same: a database whose uptime doesn’t depend on someone visiting your app every few days.

Or, we do it for you

If your app has grown past the point where a paused database is acceptable, moving it to a Postgres that stays up and stays backed up is exactly what we handle. If you want a second pair of eyes on your setup regardless of what you built it with, get a free production audit first, and we’ll tell you whether upgrading in place or moving out makes more sense for you.

FAQ

Did I lose my data when the project paused?

No. A pause stops the database, it doesn’t delete it. When you resume the project, your data comes back exactly as it was. That said, this is a good prompt to take your own backup so you’re never depending on the platform’s state alone.

How long until a Supabase project pauses?

Around 7 days of inactivity on the free tier. “Inactivity” means no requests to the database, not whether you’ve logged into the dashboard. A quiet week is enough to trigger it.

Will a keep-alive ping really stop the pause?

Yes, genuine traffic to the database resets the inactivity timer. A health check every few minutes does the job. Just keep it lightweight, one small query, so you’re not eating into your free-tier limits to stay awake.

Should I upgrade Supabase or move off it entirely?

Depends on where you’re headed. If Supabase fits your needs and you just want the pausing to stop, upgrading is the simplest fix. If you’re also hitting other limits or you need full control over backups and data location, moving to your own Postgres is the bigger but more durable move.