Monitoring Neon Serverless Postgres with Vigilmon: Connection Health, Query Endpoints & SSL Alerts

Neon is a serverless Postgres platform that separates storage from compute, auto-suspends idle branches, and spins up instantly on demand. That serverless model introduces a new class of monitoring problems: cold-start latency, branch-level health, connection pool exhaustion, and SSL certificate expiry on custom domains. Vigilmon lets you watch all of these from outside your application — catching issues before your users do.

What You'll Build

• An HTTP monitor on Neon's query API endpoint to confirm database connectivity
• A keyword assertion to detect cold-start failures and unexpected responses
• Branch-level health monitoring for staging and feature branches
• SSL certificate expiry alerts for Neon custom domains
• Alerting rules tuned for Neon's auto-suspend behavior

Prerequisites

• A Neon project with at least one database branch
• A Neon API key (from console.neon.tech → Account → API keys)
• A free account at vigilmon.online

Step 1: Identify Your Neon Query Endpoint

Every Neon branch exposes an HTTPS query endpoint. Find it in the Neon console under Connection Details for your branch. It looks like:

https://ep-quiet-mountain-123456.us-east-2.aws.neon.tech

Neon also exposes a management API at https://console.neon.tech/api/v2/. Both are worth monitoring — the query endpoint tells you whether your database is reachable, and the management API tells you whether your project and branches are healthy.

Step 2: Create an HTTP Monitor for the Query Endpoint

The simplest way to confirm Neon connectivity is to probe the connection endpoint and expect a response (even a rejection is better than silence — it means the endpoint is reachable and the Neon infrastructure is up).

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://ep-quiet-mountain-123456.us-east-2.aws.neon.tech (your branch endpoint).
3. Check interval: 60 seconds.
4. Response timeout: 15 seconds (allow for cold-start on auto-suspended branches).
5. Expected status: 200 or 4xx — the endpoint returns a protocol error (not a connection refused) when the database is up but the request isn't a valid Postgres wire protocol message. You can also use a custom health endpoint (see Step 3).
6. Click Save.

Auto-suspend caveat: Neon suspends idle compute after a configurable period (default 5 minutes on the free tier). A 60-second monitor ping keeps compute warm and eliminates cold-start latency for your users — a useful side effect.

Step 3: Add a Dedicated Health Check Endpoint

Rather than probing the raw Postgres endpoint (which Vigilmon reaches over HTTP/HTTPS, not the Postgres wire protocol), expose a thin health endpoint in your application that runs a lightweight query against Neon:

// Express/Node example
app.get('/health/db', async (req, res) => {
  try {
    const result = await db.query('SELECT 1');
    res.json({ status: 'ok', neon: 'connected' });
  } catch (err) {
    res.status(503).json({ status: 'error', message: err.message });
  }
});

Then configure Vigilmon to monitor this application-level health endpoint:

1. URL: https://your-app.example.com/health/db
2. Expected status: 200
3. Keyword: neon": "connected (verify the body, not just the status)
4. Interval: 60 seconds

This is the most reliable approach — it validates the full connection path from Neon's compute layer through your connection pool to your application.

Step 4: Monitor Neon's Project API for Branch Health

Neon exposes a REST API you can use to check project and branch status. Create a Vigilmon monitor that polls the branches API:

https://console.neon.tech/api/v2/projects/{project_id}/branches

1. Add Monitor → HTTP.
2. URL: https://console.neon.tech/api/v2/projects/YOUR_PROJECT_ID/branches
3. Request headers: Add Authorization: Bearer YOUR_NEON_API_KEY
4. Expected status: 200
5. Keyword: "ready" — branch state is ready when healthy
6. Interval: 5 minutes (branch state changes slowly)

Security note: Store your Neon API key as a secret in Vigilmon's monitor headers rather than embedding it in a public URL. Vigilmon encrypts stored headers at rest.

This monitor catches scenarios where a branch enters a degraded or unknown state — for example, after a failed migration or when Neon's storage layer has an issue.

Step 5: Monitor SSL Certificate Expiry

If you've configured a custom domain on your Neon project, add an SSL monitor to catch certificate expiry before it breaks connections:

1. Add Monitor → SSL Certificate.
2. Domain: your custom Neon domain (e.g., db.yourdomain.com).
3. Alert when expiry is within: 30 days (gives you time to renew).
4. Alert again: 14 days, 7 days, 1 day.

For the default neon.tech endpoint domains, Neon manages the SSL certificates — but monitoring them is still useful to detect infrastructure-level issues on Neon's side.

Step 6: Monitor Neon Status Page (Heartbeat Pattern)

Neon publishes a status page. Rather than relying on it manually, use Vigilmon to watch for incidents:

1. Add Monitor → HTTP.
2. URL: https://neonstatus.com/ (Neon's status page).
3. Keyword: All Systems Operational
4. Keyword must be present: yes
5. Interval: 5 minutes

When this monitor fails, you'll know a Neon-side incident is active before checking the status page manually — giving you context when your own monitors start failing.

Step 7: Configure Alerting Rules

In Vigilmon under Settings → Notifications, configure your channels:

| Monitor | Trigger | Action | |---|---|---| | DB health endpoint | Non-200 or keyword missing | Page on-call; check Neon console for compute state | | Branch API | Non-200 or "ready" missing | Investigate branch in Neon console | | SSL certificate | < 30 days expiry | Renew or rotate certificate | | Neon status page | All Systems Operational missing | Check neonstatus.com; reduce alert noise, it's a platform issue |

Alert after: 2 consecutive failures for DB health (one transient spike is common during auto-resume). 1 failure for SSL alerts.

Re-notify: every 5 minutes while the DB health monitor is down.

Neon-Specific Monitoring Considerations

| Scenario | What Vigilmon catches | |---|---| | Compute auto-suspended longer than expected | DB health monitor times out; alerts fire | | Cold-start spike > 15 s | Response timeout triggers alert | | Branch enters degraded state | Branch API keyword check fails | | Connection pool exhausted (PgBouncer) | DB health endpoint returns 503 | | Custom domain SSL nearing expiry | SSL monitor alerts at 30/14/7/1 day thresholds | | Neon platform incident | Status page keyword monitor fires |

Neon's serverless architecture makes Postgres more elastic, but it also means the database can be in more states than a traditional always-on Postgres instance. Vigilmon keeps a constant external eye on all of them — from compute warm-up to branch health to SSL validity — so you can trust your database is reachable before your users discover otherwise.

Start monitoring Neon in under 5 minutes — register free at vigilmon.online.