Neon and PlanetScale database uptime checks
Neon (serverless Postgres) and PlanetScale (Vitess MySQL) scale to zero or pause compute to save money. That is great for side projects — and confusing for monitoring, because a database socket check is not what StillOnline runs. StillOnline probes HTTP URLs; your app’s /health decides whether a paused branch or connection timeout means “down” for customers.
Quick answer
Neon and PlanetScale are reached from your app, not by external HTTP monitors directly. Add GET /health on your app (optional SELECT 1 with a 1 s timeout); use liveness-only if compute suspend causes false alerts. Register the app HTTPS URL in StillOnline — Free, one URL, five-minute interval (pricing).
Lightweight SELECT vs full app health
| Approach | Proves | False positive risk |
|---|---|---|
Liveness only ({ "status": "ok" }) | App process responds | DB can be down while check is green |
SELECT 1 in /health | DB reachable from app | Neon resume / cold start may slow probe |
Separate /ready | Strict dependency check | Use on Pro second URL if needed |
| Direct DB URL in StillOnline | Not supported | StillOnline is HTTP-only |
Design details: health endpoint design.
Neon: compute pause and branches
Neon can suspend compute on free or dev tiers. First query after idle wakes the database — your /health with DB ping may exceed probe timeout once.
| Situation | Recommendation |
|---|---|
| Dev branch auto-suspend | Do not monitor dev URL in production StillOnline project |
| Prod should never sleep | Configure Neon not to suspend prod; keep DB ping in /health |
| Accept wake-up latency | Liveness-only /health; page only on repeated failures |
PlanetScale: branches and scale
PlanetScale deprecated free tier patterns evolve — monitor production branch through your app, not admin UI. Connection limits during deploys can fail SELECT 1 briefly; keep queries minimal.
Example app health (concept)
Your framework route runs:
SELECT 1;
with a 1 second timeout, returns 200 on success and 503 on failure. StillOnline registers:
curl -sS https://api.yourproduct.com/health
Not neon.tech or planetscale.com hostnames.
StillOnline setup
- Sign in.
- New project.
- HTTP check → app
/health, GET, 200. - Status page for API consumers — health quickstart.
Settings → Connect Telegram → StillOnline bot — Telegram guide.
FAQ
Can StillOnline monitor Neon or PlanetScale directly?
No. StillOnline checks public HTTP URLs. Database uptime is inferred through your app health route that uses the DB — health endpoint design.
Why does StillOnline alert when Neon was just paused?
A /health with DB ping may time out while compute resumes. Use liveness-only health, disable suspend on prod, or tune check interval — probe tuning.
Should I use /health or /ready for Neon?
Use /health for StillOnline’s primary check (liveness). Put strict DB checks on /ready if you add a second Pro check — health endpoint design.
Further reading
Health Endpoint Design for SaaS: /health vs /ready
Choose GET /health, /api/health, or /ready for external uptime probes. Best practices for JSON, auth, DB pings, and StillOnline status pages + Telegram alerts.
Supabase backend uptime monitoring
Monitor Supabase-backed SaaS from outside: REST health, Edge Functions cold start, and StillOnline status page — don't rely on status.supabase.com alone.
Next.js SaaS health check monitoring
Route Handler /api/health in Next.js App Router: DB ping, cache skip, what not to expose publicly — StillOnline external checks and status page.
What to Monitor on an API-Only SaaS
API-first products need the right health URL, status page, and owner alerts. Monitor /health or /api/health — setup with StillOnline and Telegram bot alerts.