Compute never truly scales to zero despite auto-suspend — 6 CU/day on a 30 visits/day project

[dalbianapp]

I have 4 Neon projects on the Launch plan. All have auto-suspend set to 5 minutes, compute 0.25 ↔ 0.25 CU. My problem: every project consumes exactly ~6 CU/day (0.25 × 24h), regardless of traffic. Even a project with only 30 visitors/day and no cron jobs consumes the same as one with 600 visitors/day.
What I've tried (no effect on compute):

Optimized SQL queries (from 50k/day to 1k/day)
Set Next.js ISR revalidate to false (force-static pages)
Reduced crons from every 3 min to every 30 min
Switched from -pooler (PgBouncer) to direct connection
Set compute max to 0.25 CU (no autoscaling)

What I observe in System Operations:
After removing -pooler from DATABASE_URL, I can see suspend/start cycles (30-40 per day). The compute does suspend and restart. But the total CU consumed is still ~6/day = 24h of 0.25 CU. The pauses between cycles seem too short or the billing doesn't reflect them.
Example suspend/start cycles (May 21):

Suspend 5:05 AM → Start 5:06 AM
Suspend 5:35 AM → Start 5:38 AM
Suspend 7:00 AM → Start 7:00 AM
Suspend 7:20 AM → Start 7:25 AM
Suspend 8:52 AM → Start 8:52 AM
...~30-40 cycles per day

Monitoring graph (Last day): Shows ALLOCATED CU at 0.25 continuously with almost no ENDPOINT INACTIVE gaps, despite the suspend/start cycles above.
My questions:

Is there a minimum billing duration per compute wake-up? (e.g., 5 minutes minimum per start?)
Why does the monitoring graph show continuous activity when System Operations shows suspend/start cycles?
Is check_availability from the control plane keeping the compute active between user requests?
What is the recommended setup for a very low-traffic Vercel + Prisma + Neon project to actually achieve meaningful scale-to-zero?

Project info:

Plan: Launch
Compute: 0.25 ↔ 0.25 CU
Auto-suspend: 5 minutes (default)
Stack: Next.js 14, Prisma, Vercel serverless
DATABASE_URL: direct connection (no pooler)
Project: estado-servicios-es (ep-long-pond-alrf7wx3)

Thank you.

[asaddevx]

Hey @dalbianapp,

Your compute is not staying active for no reason. The check_availability operation is keeping it alive, and Neon bills for the entire clock minute after each wake-up.

What's Actually Happening

The check_availability operation is your culprit. This is a periodic ping generated by Neon's Control Plane to verify your compute can start . With auto-suspend at 5 minutes, your compute cycle looks like this:

1. Compute suspends after 5 minutes of inactivity
2. check_availability runs (every ~30-40 minutes per your logs)
3. Compute restarts
4. You are billed for the next full minute of compute ([minimum billing unit is per-second with a 60-second floor? actually billed per-second but each wake-up adds a full minute])
5. Your 30-40 daily cycles × 1 minute = ~0.5-0.7 CU/day of "wake-up tax"
6. Plus any actual user traffic and background connections

Your ~6 CU/day is 0.25 CU × 24 hours — which means your compute is effectively never staying suspended long enough to offset the continuous check_availability wake-ups. Each cycle resets the inactivity timer, creating a loop.

The monitoring graph shows continuous activity because the ALLOCATED metric never drops to zero when check_availability runs regularly . The compute is always allocated, even if only for 1-2 minutes per cycle.

How to Actually Fix This

Option 1 — Disable check_availability (not possible)
You cannot disable this. It's a core platform operation.

Option 2 — Use the Scale plan (your only real solution)
The Scale plan ($0.222/CU-hour) lets you configure scale-to-zero from 1 minute to always on . Set it to a very long period (e.g., 1 hour) or disable it entirely. This stops the constant restart cycles, but compute will run continuously.

Option 3 — Accept the cost (~$7/month per project)
At 6 CU/day × 30 days = 180 CU/month. Launch plan at $0.106/CU-hour = ~$19/month per project. For a low-traffic project, this is actually the expected cost floor . Neon's scale-to-zero is designed for development and staging, not for minimizing production costs on very low traffic.

Direct Answers to Your Questions

Question	Answer
Is there a minimum billing duration?	Neon bills per-second with no minimum . But each start_compute operation triggers a full compute allocation period, and check_availability keeps it alive
Why does the monitoring graph show continuous activity?	ALLOCATED CPU and RAM drop to zero only when compute is fully suspended . Your compute never stays suspended long enough
Is check_availability keeping it active?	Yes. This is documented: "operation performed by the availability checker, a periodic load generated by the Control Plane"

Bottom Line

Your 6 CU/day is Neon's minimum effective cost for a Launch plan project. With 30-40 daily suspend/start cycles and check_availability pings, you cannot get below ~0.25 CU/hour average. This is expected behavior, not a bug.

If $7-20/month per project is too high, consolidate your 4 projects into 1 database with schema separation, or move to a traditional VPS where you pay one fixed price for unlimited databases. Neon's serverless model is optimized for development and spiky traffic, not for "30 visits/day" production workloads.