Why this happens
Supabase pauses Free plan projects that show low activity over a 7-day period. "Activity" means real database requests. A front-end that only serves static pages doesn't count, which is why side projects and pre-launch apps get caught.
Per Supabase's docs:
- You get a warning email about a week before the pause, then a confirmation once it's paused.
- Paid-plan projects can't be paused for inactivity.
- A paused project can be restored from the dashboard. The docs currently give a restore window of up to one year, after which restoring from the dashboard is no longer possible.
While it's paused, your front-end may still load, but anything that talks to Supabase fails: login, signup, data loading and Edge Functions. Users often see "Failed to fetch" or an endless spinner.
How to fix it, step by step
1. Restore it. Go to the Supabase Dashboard, open the organization, open the paused project, and click Resume project. Restoring can take a few minutes.
2. Check it's back.
curl -i "https://<project-ref>.supabase.co/auth/v1/health" -H "apikey: <publishable-or-anon-key>"Then log in on your live site in a private window.
3. Check what else depended on it. Run any cron or scheduled function that failed during the pause. Stripe events that failed while it was down can be resent from the webhook endpoint's Event deliveries tab, and Stripe retries failed deliveries for up to three days.
4. Stop it happening again. Pick one:
- Upgrade the project to a paid plan. Supabase's own recommendation, and the only guaranteed option.
- Generate real activity. Supabase says a few user requests to the database each day over the week is typically enough. A real app with users usually is. For a quiet project, a scheduled job that makes a genuine query works, for example a daily GitHub Actions run:
# .github/workflows/supabase-activity.yml
on:
schedule: [{ cron: '0 9 * * *' }]
jobs:
query:
runs-on: ubuntu-latest
steps:
- run: >
curl -fsS "${{ secrets.SUPABASE_URL }}/rest/v1/<a_public_table>?select=id&limit=1"
-H "apikey: ${{ secrets.SUPABASE_PUBLISHABLE_KEY }}"Use a table that's meant to be publicly readable under your RLS, or a small RPC function you create for this purpose. Don't open a private table to make this work.
5. Don't ignore the warning email. Make sure the project owner's email goes to an inbox someone reads.
Fix prompt for your AI builder
Paste this into Lovable, Bolt, Cursor, Claude, ChatGPT, Replit, v0 or whichever tool you build with. Replace the bracketed parts first.
Our Supabase project was paused, so login and data loading failed. It's restored now. Please:
1. Make our app show a clear "We're having trouble connecting, please try again shortly" message when Supabase requests fail, instead of a blank screen or endless spinner.
2. Add a GitHub Actions workflow that runs once a day and makes one real read query against a table that is meant to be public (or a small RPC function), using the publishable key from repository secrets.
Don't make any private table readable, and don't put secret keys in the front end.How to catch this next time
A pause tends to happen in a quiet week, which is exactly when nobody is testing the app.
Heedza opens your live landing, signup, login and checkout pages in a real browser on a schedule and emails you a screenshot and a fix prompt when a page fails to load or its form disappears. A static login form can keep rendering even while the database behind it is paused, so Supabase's warning email is still your first line of defence. Run the free scan to see what Heedza checks on your live URL.