What Happens on Your Team
The Full-Stack Developer
Can't reproduce the error locally, because the local database never sleeps. Adds logging, and finally sees it: the first query after an idle period takes far longer than usual, and the route's timeout is set too tight.
The real cost: Intermittent errors are the hardest kind to find. They show up as vague complaints ('it was broken earlier') and disappear the moment you look. Without data, you spend hours guessing.
What they should have had: A health route that queries Neon, monitored on a schedule. Response-time history shows exactly when the slow first requests happen, and a failure alert fires if the database ever doesn't come back at all.
The Indie Hacker
Chose Neon's free plan for a side project because scale-to-zero keeps it cheap. Then a launch post brings a burst of visitors at once, and some of them hit errors while the compute wakes and connections pile up.
The real cost: On the free plan, scale-to-zero can't be turned off. That's fine for a quiet project, but launch-day visitors are the ones you most want to impress, and they're the ones who see the cold start.
What they should have had: A monitor on the app's health route with a slow-response threshold. It tells you how long cold starts actually take in production, which is the evidence you need to decide when a paid plan (where scale-to-zero can be adjusted or disabled) is worth it.
The Tech Lead
The app is down and the team splits three ways: one checks hosting, one checks the code deploy, one checks Neon. Twenty minutes later they learn the database was fine all along; the outage was a bad environment variable pointing at the wrong branch.
The real cost: When you can't tell which layer failed, everyone debugs everything. Branching makes this easier to get wrong: a preview branch's connection string in production looks healthy until real data is missing.
What they should have had: Separate monitors for the page, the health route and a real data route. If the page is up but the health route fails, it's the database connection. If all three fail, it's hosting. The alert tells you where to look first.
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/healthAn app route that runs a trivial query (SELECT 1) against Neon and returns 200 only if it succeedsyour-app.comYour main page, to separate a frontend or hosting outage from a database oneyour-app.com/api/your-busiest-endpointA real data route, to watch response time creep from cold starts or slow queriesWhat You Should Actually Do
- 1Add 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
- 2Monitor your main page separately so a database failure and a hosting failure don't look the same
- 3Watch response times on a real data route; cold starts after scale-to-zero show up as periodic slow requests
- 4Set a slow-response threshold so creeping latency alerts you before it turns into timeouts
- 5Double-check which Neon branch production points at after every deploy; a wrong connection string fails quietly
- 6Check 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 neonstatus.com. Monitoristic doesn't replace this — it complements it. The official page tells you when Neon reports an issue. Your own monitor tells you when your connection is affected, often before the status page updates. You also get push alerts instead of checking a webpage manually.
The 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.