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
// 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 });
}
});
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
- Sign up at vigilmon.online (free tier available)
- Click Add Monitor
- Select HTTP (for health endpoints) or TCP (for port checks)
- Set your check interval — 1 minute is ideal for databases
- 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';
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;
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';
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)