# How to Monitor Neon Uptime

> Neon is serverless Postgres: compute and storage are separated, databases branch like code, and idle compute scales to zero so you only pay for what runs.

*Source: https://monitoristic.com/monitor/neon*

---

## Why Monitor Neon?

Neon's compute suspends after a few minutes without queries and wakes on the next connection. That's great for cost, but it means your app's first request after a quiet period pays a cold start, and if the compute can't wake, every query fails. Because your app talks to Neon over Postgres connections, the only way an outside monitor sees a Neon problem is through your app, so monitoring the right app endpoint is what tells you the database is reachable.

## What to Monitor

- `your-app.com/api/health` — An app route that runs a trivial query (SELECT 1) against Neon and returns 200 only if it succeeds
- `your-app.com` — Your main page, to separate a frontend or hosting outage from a database one
- `your-app.com/api/your-busiest-endpoint` — A real data route, to watch response time creep from cold starts or slow queries

## What You Should Actually Do

1. Add a health route to your app that runs SELECT 1 against Neon and returns 200 only on success, then monitor it; an HTTP monitor can't open a Postgres connection itself, so this route is your window into the database
2. Monitor your main page separately so a database failure and a hosting failure don't look the same
3. Watch response times on a real data route; cold starts after scale-to-zero show up as periodic slow requests
4. Set a slow-response threshold so creeping latency alerts you before it turns into timeouts
5. Double-check which Neon branch production points at after every deploy; a wrong connection string fails quietly
6. Check neonstatus.com during incidents, but remember it reports platform issues, not your project's connection settings or branch mix-ups

## Neon's Official Status Page

Neon publishes real-time status at https://neonstatus.com. Your own monitor complements it by catching connection-level issues, often before the status page updates.

## Takeaway

Neon makes Postgres cheap to run by sleeping when you're idle. That trade-off is worth it, as long as you can see what it costs you: cold starts, wake-up failures and connection mistakes. A monitored health route turns those from mystery bugs into measured, alertable events.

## Frequently Asked Questions

### Can an uptime monitor connect to my Neon database directly?

Not an HTTP monitor like Monitoristic. It checks URLs, not Postgres connections. The reliable approach is a small health route in your app that runs a trivial query against Neon and returns 200 only when it succeeds. Monitoring that route tells you the database is reachable from your app, which is what your users actually depend on.

### Will a monitor keep my Neon compute awake?

If your health route queries the database on every check, each check is activity, so a frequent enough interval can keep the compute from suspending. Whether you want that is a cost decision: it trades cold starts for compute time. If cold starts are a problem for real users, Neon's paid plans let you adjust or disable scale-to-zero instead.

### How long does a Neon cold start take?

Neon says waking a suspended compute normally takes a few hundred milliseconds, and can take longer after a long idle period. Your own numbers depend on your region, driver and queries, so monitor response times on a health route to see what your users experience.

### How is this different from neonstatus.com?

Neon's status page covers platform-wide incidents. Your monitor covers your project: your connection string, your branch, your app's route to the database. Most outages you'll actually hit are on that side, and they never appear on a vendor status page.