neon compute never scaled to zero because a 30s health check kept the branch awake Database Costs

Add to the list of things that quietly keep serverless databases awake:

• migration tooling that opens an advisory-lock connection at boot and holds it
• a background job runner polling a jobs table every few seconds
• an admin dashboard tab someone left open with a 10 second refresh
• log shippers or metrics exporters querying pg_stat_*
• your own local development environment connected to production because of a stale .env

The last one has happened to two people I know and the tell is compute activity in a timezone where you have no users.

730 compute hours in a 730 hour month is the cleanest diagnostic in this whole thread. Any time you see that number, something is polling.

On what a health check should do: split it into two endpoints.

• /health - liveness. Is this process running and able to respond. No dependencies, returns a constant. This is what your uptime monitor hits every 30 seconds and it should touch nothing.
• /ready - readiness. Can it actually serve, including dependencies. Hits the database. Called by your orchestrator on deploy, or by you at a much lower frequency.

A liveness check that fails when a dependency is down is actively harmful anyway - it tells your platform to restart a perfectly healthy process because the database is having a moment, and restarting will not help.

If you want database monitoring, monitor the database. Do not infer it by poking your app, and definitely do not do it at a frequency that defeats the billing model you chose.

One extra thing to check: any connection pooler, ORM keepalive, or long-lived connection also counts as activity on most of these platforms. Suspend usually needs no connections, not just no queries. A pooler holding one idle connection open forever will keep the compute up just as effectively as your health check.

Worth asking whether you want scale-to-zero at all, rather than just fixing this instance of it.

The economics only work if you have long genuine idle stretches. If you get a request every few minutes during waking hours, you are paying cold start latency all day - hundreds of milliseconds on the first query after a suspend, sometimes more - in exchange for saving money during hours nobody is awake anyway.

Run the numbers on your actual traffic shape. For a lot of small products the honest answer is a small always-on instance with a hard ceiling on autoscaling, because the bill is predictable and every request is fast. Scale-to-zero is genuinely great for preview branches and dev environments, where the idle really is 95%.

Whatever you do, set a budget alert at 2x your expected spend on day one. $61 is a cheap lesson. The same bug on a bigger instance class is a very expensive one and the failure mode is identical - you find out at the end of the month.

Health checks are the only code we write specifically to run forever and then never think about again.