How to stop Neon autosuspending your database

Your first database query of the morning takes a few seconds; every one after is instant. Neon didn't break — it scaled your compute to zero while nobody was using it, and that first query paid to wake it up.

Neon calls this Scale to Zero, and it's a feature, not a fault. But whether you want to stop it depends entirely on which problem you actually have — and getting that backwards can cost you money.

What Scale to Zero does

Neon separates storage from compute. Your data always lives in storage; the compute is the part that runs queries. After a short spell with no queries — around five minutes on the free plan — Neon suspends the compute so you're not billed for it sitting idle.

The next query starts the compute back up. That takes a beat — usually under a second, sometimes a few — and only the first query after a suspend pays it. Everything after runs at full speed until the next idle spell.

~5 min

idle before a free-plan compute scales to zero

sub-second

typical cold start on the next query

storage kept

your data is never suspended, only the compute

compute-hours

what you're billed on — idle time is the cost you're cutting

First, which problem do you have?

Two very different people search for how to stop Neon suspending, and they want opposite things:

If your problem is latency — that first slow query hurts a user-facing request — you want to keep the compute warm. If your problem is a surprise bill, you almost certainly want the opposite: Scale to Zero is what keeps a low-traffic project cheap, and fighting it is how the compute-hours climb.

If you genuinely need it warm

For a latency-sensitive app where the cold query lands on a real user, the fix is a keep-alive: run a trivial SELECT 1 every few minutes so the compute never idles long enough to suspend. Go in knowing it raises your bill — that's the trade you're making on purpose.

Write a GitHub Actions workflow that runs a trivial query against my Neon Postgres database every few minutes so the compute doesn't scale to zero, and fails loudly if the query errors.

Requirements:
- Schedule every few minutes, plus workflow_dispatch for manual runs.
- Connect using a DATABASE_URL I'll store as a GitHub secret (never hardcode it).
- Run a cheap query like SELECT 1.
- Exit non-zero (mark the run red) if the query fails, so a real database problem isn't a silent green check.
- Add a top comment warning me that: (a) keeping compute always-on uses far more of my monthly compute-hours than letting it scale to zero, so this can raise my bill, and (b) GitHub disables scheduled workflows after 60 days of no repo activity.

Give me the full workflow file and tell me where to add the DATABASE_URL secret.

Store the connection string as a secret, never in the workflow file, and make a failed query turn the run red — otherwise a keep-alive pinging a broken database looks identical to one pinging a healthy one.

Knowing when it's actually down

A keep-alive can't report its own death — GitHub disables scheduled workflows after 60 days of repo inactivity, and then the queries just stop. And a warm compute doesn't mean a healthy app; the database can be up while your API fails for a dozen other reasons.

The reliable signal is watching the app from outside your stack. It's the same idle-sleep problem that hits Supabase and Render; the full cross-host playbook is in how to keep a free backend awake.