Why Supabase pauses your project — and how to stop it happening again

You open your app to show someone, and it's throwing errors. The database is gone. Nothing changed — you just hadn't touched it in a week. Supabase paused it.

This is the single most common way a Supabase side project dies, and it catches people precisely because nothing went wrong. No bug, no bad deploy. The project was quiet, and quiet is exactly what triggers it.

Here's the real mechanic behind the pause, the deadline nobody mentions, and why the usual fix quietly stops working.

Why Supabase pauses free projects

Supabase pauses Free-tier projects after about seven days without activity. It's watching real usage — database queries and API traffic — not whether you have the dashboard open.

So a project nothing has talked to for a week gets paused, even one you fully intend to come back to. Paid (Pro) projects are never paused. The pause is how the free tier stays free.

The cruel part is the timing. Side projects are quiet by nature, so the pause lands right when you've stopped watching — and you find out weeks later from a dead demo link or a user hitting an error page.

What a paused project actually looks like

A paused project doesn't go halfway. Everything it serves — database, auth, storage, edge functions — stops at once and answers HTTP 540, Supabase's official "project paused" status code, on every request.

Your data is not deleted. The database volume is frozen in place. Any app pointing at the project just starts erroring, which is usually how people discover the pause in the first place.

~7 days

of inactivity before a Free project pauses

HTTP 540

the code a paused project returns on every request

90 days

until one-click restore is disabled

$0

data lost when it pauses — it's frozen, not deleted

Want to know your project's status right now without logging in? One request to its API gateway settles it — a paused project answers 540, an awake one answers normally.

How to bring a paused project back

1. Log in to the Supabase dashboard and select the paused project.
2. Click Restore project and confirm. It typically comes back within a few minutes, with all data intact.
3. Mind the clock. After 90 days paused, one-click restore is disabled — you're into downloading the backup and restoring it into a fresh project by hand. Long enough after that, the project and its infrastructure are removed entirely.

How to keep it from pausing again

Two real options. Upgrade to Pro — paid projects never pause — or give the project a genuine heartbeat: a scheduled job that runs a small query every day or two so the project never looks idle.

A GitHub Action is the usual choice, and it's free. The trouble is that keep-alive jobs fail silently, and a keep-alive you can't see failing is worse than none — it convinces you you're covered.

Three ways the job dies without a word:

• GitHub disables it. Scheduled workflows are turned off automatically after 60 days of no repo activity — exactly the dormancy a side project has.
• The token expires. A rotated or expired key makes every run fail, but the workflow itself still "runs," so nothing screams.
• The schema moves. Someone renames or drops the table the ping queried, and the query 404s into the void.

You can close most of that gap by writing the job so a failed ping turns the run red instead of green. Hand this to your AI tool and it'll generate one that does:

Add a Supabase keep-alive to my repo as a GitHub Actions workflow.

Requirements:
- Runs on a schedule every 2 days (cron), plus workflow_dispatch so I can run it manually.
- Sends one lightweight authenticated query to my Supabase project so it counts as real activity (e.g. a select on a tiny table using the service role key from a repo secret named SUPABASE_URL and SUPABASE_KEY).
- Fails the job with a clear error if the query does not return HTTP 200, so a broken key or paused project shows up as a red run instead of a silent pass.
- Add a comment reminding me that GitHub disables scheduled workflows after 60 days of no repo activity, so this job can stop running on its own.

Give me the full .github/workflows/keep-alive.yml file and tell me exactly which repo secrets to set.

The honest fix: monitor the project, not just the script

The reliable answer isn't a better script — it's watching the thing you actually care about. Point a monitor at the project's gateway, and the instant it starts answering 540, you get an email. Not three weeks later. The moment it happens.

That's exactly what Tell Me When Down does, and it closes the loop the keep-alive can't: it also watches the heartbeat job itself, so a workflow GitHub quietly disabled shows up as a silent cron — the same failure mode that runs through this whole cluster.

Same trap, different host? If you're on Render's free tier, its web services spin down after 15 minutes idle and cold-start on the next request — a gentler version of the same problem, and worth a quick check if that's where your app lives.