Supabase free-tier project keeps pausing: inactivity limits vs. moving to Pro with micro compute

Direct answer for your workload

Free-tier projects are paused after a period of inactivity. While paused, the Postgres database and all API endpoints are not accepting traffic. That is an availability problem, and it also means any work that depends on the database being reachable will not run.

Confirmed behavior: the Supabase console shows a Paused status for an inactive free project, and requests to the project return a service-unavailable response until resumed. The data and storage remain intact and resuming is free.

Likely explanation for your case: scheduled jobs and cron triggers that run inside Supabase or that call Supabase from an external scheduler will fail while paused. A first user request after a quiet stretch will hit the paused state and experience cold start latency from the resume process, not normal query latency.

1. Does pausing affect more than availability?

Yes. Availability is the core impact. Because the database instance is stopped, any Supabase Cron, database scheduled jobs, webhooks that write to Postgres, and health checks that query the DB will be blocked until the project is resumed. For a low-traffic side project with no strict uptime requirement, that may be acceptable if you can tolerate manual resume and missed runs. If you rely on time-sensitive cron work, the free tier is unsuitable without a keep-alive.

2. Is Pro with micro compute the minimal always-on option and what to check before resizing

On Pro, adding the smallest compute add-on removes the inactivity pause rule, so the project stays running even with no traffic. That is the minimal always-on configuration.

Before upgrading, check these constraints that affect your plan:

• Disk can generally be expanded but not shrunk. Choose a size you will not need to reduce later.
• Downgrade from Pro back to free is possible, but you will re-enter the inactivity pause rules and any compute add-on will be removed.
• Verify current pricing and compute sizes in your dashboard, as plans and thresholds change over time.

3. Reliable verification that pausing is what users are hitting

1. Open the project overview in the Supabase console. A banner or status label reading Paused confirms the state.
2. Check the Usage section for days since last activity. The console typically surfaces inactivity metrics.
3. Test an endpoint from a client. Example:

   curl -i https://<project-ref>.supabase.co/rest/v1/
   

   A service-unavailable response while the console shows Paused is consistent with a pause.
4. Review Logs for pause/resume events. The console logs the time the project entered Paused and when it was resumed.
5. Resume from the dashboard and observe the status change to Running and API responses returning to normal.

Assumption and uncertainty: the exact inactivity threshold has changed over time and is subject to policy updates. Current documentation should be verified in your dashboard before deciding on timing.

One missing detail that changes the recommendation: what inactivity threshold is currently shown for your project in the console or billing/usage page. If your quiet periods are shorter than that threshold, a resume or keep-alive may be sufficient; if they regularly exceed it, Pro micro compute or a minimal keep-alive is the practical path.