DEV Community

Vigilmon
Vigilmon

Posted on

How to Monitor Your PostgreSQL Database with Vigilmon

How to Monitor Your PostgreSQL Database with Vigilmon

PostgreSQL is the backbone of countless production applications — and when it goes down, everything stops. Effective database monitoring isn't just about knowing when Postgres crashes; it's about catching degradation before it becomes an outage.

In this guide, we'll cover how to monitor your PostgreSQL database using Vigilmon — a free uptime monitoring platform designed for developers.

Why Monitor PostgreSQL?

Postgres failures rarely announce themselves. They creep in:

  • Connection pool exhaustion — your app starts refusing new connections
  • Long-running queries — one bad query locks tables and cascades failures
  • Replication lag — your replica falls behind; reads serve stale data
  • Disk pressure — write-ahead logs balloon; Postgres refuses writes
  • Process crashes — the postmaster dies silently

By the time users complain, you've already lost signups, orders, or worse.

Setting Up Postgres Health Checks

Option 1: HTTP Health Endpoint (Recommended)

The cleanest approach: expose a lightweight /health endpoint in your app that queries Postgres and returns 200/503 based on the result.

# Flask example
from flask import Flask, jsonify
import psycopg2
import os

app = Flask(__name__)

@app.route('/health/db')
def health_db():
    try:
        conn = psycopg2.connect(os.environ['DATABASE_URL'], connect_timeout=3)
        cur = conn.cursor()
        cur.execute('SELECT 1')
        cur.close()
        conn.close()
        return jsonify({'status': 'ok', 'db': 'connected'}), 200
    except Exception as e:
        return jsonify({'status': 'error', 'db': str(e)}), 503
Enter fullscreen mode Exit fullscreen mode
// 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 {
    await pool.query('SELECT 1');
    res.json({ status: 'ok', db: 'connected' });
  } catch (err) {
    res.status(503).json({ status: 'error', db: err.message });
  }
});
Enter fullscreen mode Exit fullscreen mode

Option 2: TCP Port Monitor

If you can't modify your app, monitor the Postgres port directly. Postgres listens on TCP port 5432 by default.

In Vigilmon, add a TCP monitor:

  • Host: your-db-host.example.com
  • Port: 5432
  • Check interval: 1 minute

This confirms the Postgres process is running and accepting connections — but doesn't verify it can actually execute queries.

Configuring Vigilmon for Database Monitoring

  1. Sign up at vigilmon.online (free tier available)
  2. Click Add Monitor
  3. Select HTTP (for health endpoints) or TCP (for port checks)
  4. Set your check interval — 1 minute is ideal for databases
  5. Configure alerting thresholds

Vigilmon checks from multiple regions simultaneously — this means you won't get false positives from regional network issues. Both checks must fail before an alert fires.

What to Monitor Beyond Uptime

Raw uptime isn't enough for Postgres. Pair Vigilmon with these:

Connection Count

SELECT count(*) FROM pg_stat_activity WHERE state = 'active';
Enter fullscreen mode Exit fullscreen mode

Alert when this approaches max_connections (default 100).

Replication Lag (for replicas)

SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_seconds;
Enter fullscreen mode Exit fullscreen mode

Alert when lag_seconds > 30.

Long-Running Queries

SELECT pid, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state = 'active' AND now() - query_start > interval '30 seconds';
Enter fullscreen mode Exit fullscreen mode

Expose these as sub-endpoints and monitor them with Vigilmon alongside your main DB check.

Alert Configuration

In Vigilmon, configure:

  • Immediate alert on HTTP 503 or TCP connection failure
  • Response time alert if your DB health check takes >500ms
  • Multi-channel alerts: email, Slack, PagerDuty webhook

Production Checklist

  • [ ] HTTP health endpoint queries Postgres with a timeout
  • [ ] TCP port 5432 monitored as a secondary check
  • [ ] Replication lag endpoint for read replicas
  • [ ] Vigilmon alerts go to your on-call channel
  • [ ] Test alert delivery by temporarily returning 503
  • [ ] Maintenance windows set for planned Postgres upgrades

Common PostgreSQL Failure Modes

Failure Symptom Vigilmon Check
Process crash TCP port closes TCP monitor fires immediately
Connection exhaustion HTTP 503 HTTP monitor catches 503
Long lock Health check slow Response time threshold
Replication lag /health/replication returns 503 Separate HTTP monitor
Disk full Postgres refuses writes Custom endpoint

Wrapping Up

PostgreSQL monitoring with Vigilmon takes about 10 minutes to set up. A simple SELECT 1 health endpoint + a Vigilmon HTTP check catches 90% of real-world failure modes.

Start with the basics: an HTTP health endpoint that queries Postgres and returns 200 when healthy. Then layer in connection count, replication lag, and query performance checks as your app matures.

Set up your first Postgres monitor on Vigilmon →


Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

Top comments (0)