How to Monitor PostgreSQL Database Health with Vigilmon (Free External Checks)

PostgreSQL is the backbone of most production applications. When Postgres goes down or slows down, your entire application grinds to a halt. This guide shows how to use Vigilmon to monitor your PostgreSQL database health externally - no agent installation required.

The Problem with Database-Only Monitoring

Most database monitoring tools (pg_stat_statements, pgBadger, pgMonitor) tell you what's happening inside Postgres. They show slow queries, lock contention, and vacuum performance.

But they don't tell you:

• Whether your application can reach the database from the outside
• Whether your database connection pool is exhausted
• Whether a firewall rule change just blocked connections
• Whether your database health endpoint is responding to external requests

That's where external HTTP monitoring with Vigilmon fits in.

Setting Up a Database Health Endpoint

The best approach for external PostgreSQL monitoring is exposing a /health or /db-health endpoint in your application that tests the database connection:

Node.js (Express) Example

const { Pool } = require('pg');
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

app.get('/health/db', async (req, res) => {
  try {
    const result = await pool.query('SELECT 1');
    res.json({ 
      status: 'ok', 
      db: 'connected',
      timestamp: new Date().toISOString()
    });
  } catch (err) {
    res.status(503).json({ 
      status: 'error', 
      db: 'disconnected',
      error: err.message 
    });
  }
});

Python (FastAPI) Example

from fastapi import FastAPI
import asyncpg

app = FastAPI()

@app.get("/health/db")
async def db_health():
    try:
        conn = await asyncpg.connect(os.environ["DATABASE_URL"])
        await conn.execute("SELECT 1")
        await conn.close()
        return {"status": "ok", "db": "connected"}
    except Exception as e:
        return JSONResponse(
            status_code=503,
            content={"status": "error", "db": str(e)}
        )

Laravel (PHP) Example

Route::get('/health/db', function () {
    try {
        DB::connection()->getPdo();
        return response()->json(['status' => 'ok', 'db' => 'connected']);
    } catch (\Exception $e) {
        return response()->json(['status' => 'error', 'db' => $e->getMessage()], 503);
    }
});

Ruby on Rails Example

# config/routes.rb
get '/health/db', to: 'health#database'

# app/controllers/health_controller.rb
class HealthController < ApplicationController
  def database
    ActiveRecord::Base.connection.execute("SELECT 1")
    render json: { status: 'ok', db: 'connected' }
  rescue => e
    render json: { status: 'error', db: e.message }, status: 503
  end
end

Monitoring Your Database Health Endpoint with Vigilmon

Once you have a health endpoint, set up a Vigilmon monitor:

1. Sign up free at vigilmon.online
2. Click New Monitor ? HTTP(S)
3. Configure:

URL: https://yourapp.com/health/db
Method: GET
Expected status: 200
Keyword check: "connected" (confirms DB is actually reachable, not just HTTP 200)
Interval: 3 minutes
Multi-region: enabled

The keyword check is critical - your health endpoint should return HTTP 503 when the DB is down, but adding a keyword check as a backup ensures you catch cases where the endpoint incorrectly returns 200.

What This Monitors

With this setup, Vigilmon will alert you when:

1. Database is unreachable: The /health/db endpoint returns 503
2. Application can't start: The endpoint returns 500 or doesn't respond
3. Connection pool exhausted: Your pool timeout triggers a 503
4. Network/firewall issue: The endpoint times out
5. Application crash: No response at all

What This Doesn't Monitor (And How to Handle It)

External HTTP monitoring can't see inside Postgres itself. For internal metrics, combine Vigilmon with:

• pg_stat_activity: Long-running query detection
• pg_stat_replication: Replication lag monitoring
• pg_stat_bgwriter: Checkpoint and buffer monitoring
• Prometheus + postgres_exporter: Full metrics pipeline

Think of Vigilmon as your "can the application reach the database?" check, and internal tools as your "what's happening inside the database?" check.

Monitoring PostgreSQL Connection Pools

If you use PgBouncer or a similar connection pooler, add a separate health check:

URL: https://yourapp.com/health/pool

Your pool health endpoint should report both DB connectivity AND pool saturation:

app.get('/health/pool', async (req, res) => {
  const poolStats = {
    total: pool.totalCount,
    idle: pool.idleCount,
    waiting: pool.waitingCount
  };

  if (pool.waitingCount > 10) {
    return res.status(503).json({ 
      status: 'degraded', 
      pool: poolStats,
      message: 'Connection pool under pressure'
    });
  }

  res.json({ status: 'ok', pool: poolStats });
});

PostgreSQL Read Replica Monitoring

If you have read replicas for scaling, monitor them separately:

Monitor 1: Primary DB health    yourapp.com/health/db
Monitor 2: Read replica health  yourapp.com/health/db-replica

A failed read replica might not immediately break your app (if writes still work), but it's important to know about before the primary fails and you're suddenly sending all traffic to a replica that's also down.

Response Time Alerts for Database Health

Slow DB health checks are a leading indicator of performance problems:

• Under 100ms: Normal
• 100-500ms: Monitor closely
• Over 500ms: Investigate immediately
• Over 1s: Alert - your DB is under serious load

Configure Vigilmon's response time alerting to trigger when your health endpoint takes longer than 500ms.

Sample PostgreSQL Monitoring Setup

Monitor 1: App + DB health      yourapp.com/health/db         99.95% SLA
Monitor 2: Connection pool      yourapp.com/health/pool       99.95% SLA
Monitor 3: Read replica         yourapp.com/health/db-replica 99.9% SLA
Monitor 4: Database admin UI    pgadmin.yourapp.com           99.8% SLA

Start Monitoring Your PostgreSQL Database

Set up free database monitoring at vigilmon.online. Takes under 5 minutes and requires no agent installation on your database server.

When Postgres goes down, you want to know before your users do.