Everything broke and you changed nothing? Supabase paused your project.
Sign-in stops working. Every list comes back empty. Saves fail. And the last thing you deployed was a week ago. Free-plan Supabase projects pause after roughly a week of inactivity, and the pause is silent — no warning email arrives when your app goes dark. Here is how to confirm it in under a minute, restore it, and make sure the next quiet week doesn’t do the same thing.
Nothing in your app changed. That’s the whole problem.
Supabase pauses free-plan projects that see little activity across roughly a week, to reclaim server resources. The database stops accepting connections until someone restores it from the dashboard. Your code is untouched, your last deploy was fine, and the outage starts on a day when nothing happened — which is exactly why people spend an afternoon debugging application code that was never broken.
It hits vibe-coded and no-code apps hardest, because the pattern that causes it is so normal: you ship something, traffic is light while you find your first users, and the quiet stretch that follows is indistinguishable from abandonment as far as the pause timer is concerned. The app that most needs to work when a prospect finally clicks the link is the one most likely to be asleep.
Six signs it’s a pause, not a bug
Everything database-backed broke at once
Symptom: Sign-in fails, lists come back empty, saves error — all at the same moment, with no deploy behind it.
Fix: Breadth is the clue. A code bug is usually narrow; a paused project takes out every feature that touches the database simultaneously. Check the dashboard before you read a single line of your own code.
The outage started on a quiet day
Symptom: Nothing was released, nobody touched settings, and the failure began during a low-traffic stretch — often a weekend or a holiday.
Fix: That timing is the signature. Pausing is triggered by inactivity, so the outage begins precisely when there was nothing happening to trigger anything at all.
The dashboard says paused, not errored
Symptom: Supabase shows the project as paused with a restore button, rather than reporting a fault.
Fix: Restore it from the dashboard and expect a short delay while the database comes back up. Requests will keep failing until it finishes, so wait for the project to report healthy before you conclude the fix did not work.
A customer-facing app is on the free plan
Symptom: The project that just went down is the one real users depend on.
Fix: Move it to a paid plan. Anything a paying customer touches should not be one quiet week away from a full outage — the plan cost is smaller than a single day of an app that silently stopped working.
The keep-alive doesn't touch the database
Symptom: You added a scheduled ping and the project paused anyway.
Fix: Point the schedule at an endpoint that genuinely reads from Postgres. A request that hits a static page, a cached route, or a handler that never queries the database is not activity as far as the pause timer is concerned.
Nobody was watching, so a user told you
Symptom: You found out from a support email, hours or days after the app stopped working.
Fix: The pause is silent by design — no email lands the moment your app goes dark. An external check that reads from the database both catches the outage and counts as the activity that helps prevent it.
Paste this into your incident notes
Supabase paused-project triage
[ ] Open the Supabase dashboard FIRST. Read the project state.
Paused -> everything below explains itself. Stop debugging code.
[ ] Confirm the shape of the failure before restoring:
- does every database-backed feature fail, or just one?
- was anything deployed in the last 7 days?
- do static / cached pages still answer?
[ ] Restore the project from the dashboard.
[ ] WAIT for the project to report healthy. Requests fail until it does,
so a still-failing app 30 seconds later is not a failed restore.
[ ] Re-test the flows that broke: sign-in, a read, a write.
[ ] Decide the plan question honestly:
- real customers touch this project -> move to a paid plan
- genuinely a side project -> keep it free, accept the risk
[ ] If it stays free, schedule a real query (not a static page ping)
so the project registers as active.
[ ] Add an external check on a database-backed route, so the next
outage reaches you and not a customer.One check that both detects it and helps prevent it
This is the rare failure where monitoring does double duty. A Nightlamp api_canary calls a database-backed endpoint on a schedule, which proves the database still answers — and because it is a real query rather than a static ping, it is also the activity that keeps a project from drifting toward idle in the first place.
Around it, an http_status monitor catches the resulting errors on public pages, and a browser_journey confirms sign-in still completes end to end rather than failing at the first query. That last one matters more than it sounds: a paused database usually breaks authentication before anything else a visitor would see, so the login flow is where the outage becomes real for a customer.
Don’t find out from a customer next time
Start a trial and point one check at a route that reads from your database. Nightlamp runs it around the clock, tells you the moment it stops answering, and keeps the project registering real activity in between — so a quiet week stays quiet instead of turning into a silent outage.
Start 14-day trial · no cardNewsletter
One real no-code incident + the fix, monthly
A post-mortem from a real no-code outage — what broke, how it was found, and the fix — once a month. Confirming also gets you the no-code incident runbook pack.
Double opt-in. One-click unsubscribe. No spam, ever.