How to monitor
How to monitor a PostgreSQL database
Your app is only as available as its database. Here's how to monitor PostgreSQL reachability, connectivity and health from the outside — plus what to watch and how to alert.
Your application's availability is capped by your database's availability. If PostgreSQL is unreachable or can't serve queries, everything above it fails. Here's how to monitor Postgres reliably — without exposing it to the internet.
Two solid approaches
1. TCP reachability check (quick)
A TCP check confirms the database port (default 5432) is open and accepting connections.
- Fast to set up: create a TCP monitor on your DB host and port.
- Good for catching a down host, crashed service, or firewall change.
- Limitation: an open port doesn't guarantee the database can actually run queries.
A TCP check works when the host is publicly reachable. If Postgres is private (as it usually should be), use the query heartbeat below instead of exposing 5432.
2. Query-based heartbeat (stronger)
The best signal is a job that actually uses the database and reports health:
# Runs on a schedule inside your network
psql "$DATABASE_URL" -c 'SELECT 1' > /dev/null 2>&1 \
&& curl -fsS -m 10 https://statuscat.co/ping/your-db-heartbeat-id > /dev/null
- The
SELECT 1proves the database can serve queries, not just accept connections. - The
&&means the ping only fires on success — so a query failure becomes a missing heartbeat, and StatusCat alerts you. - Nothing is exposed publicly; the job reaches out.
Set the heartbeat interval to how often the job runs, with a small grace period. (More on this pattern in how to monitor a cron job.)
What else to watch
- Connectivity from the app — pair the DB heartbeat with a check on your app's
/healthendpoint, which should touch the database (how to monitor an API). - The database host — a TCP or ICMP check on the host catches infrastructure-level failures.
- Backups — a heartbeat on your backup job so a silent backup failure doesn't go unnoticed.
- Thresholds (connections, replication lag, disk) — emit these from inside and let a failing heartbeat page you.
Put it together
A robust Postgres setup is usually: a query heartbeat for "can it serve queries," a TCP/host check for "is it reachable," and a backup heartbeat for "are we protected." Wire alerts and escalation so the right person hears about it fast.
StatusCat supports TCP, ICMP and heartbeat monitors alongside HTTP/DNS/SSL checks, free for 50 monitors. Start with what uptime monitoring is if you're new to this.