How to Monitor a Postgres Port for Uptime
A Postgres instance can be technically "up," the process running, the server responding to pings, while still being unable to accept a single new connection. Hit max_connections, and every new client gets rejected. Misconfigure a security group after a deploy, and the port that was reachable yesterday isn't today. A replica that's fallen too far behind during a failover can leave applications pointed at a database that's alive but not actually usable. None of these show up as "the server is down," they show up as "the port stopped accepting connections," which is a narrower and easier thing to check for, if you're actually watching for it.
This guide covers setting up a TCP port monitor against your Postgres instance with Downdar, along with what that kind of check does and doesn't tell you.
What You Will Need
A Downdar account and API key, and a Postgres instance with its port (5432 by default) reachable from wherever Downdar's checkpoints run from. If your database currently only accepts connections from your application servers, you'll need to decide how to expose it to monitoring traffic specifically, more on that below.
Creating a TCP Port Monitor
The /api/v1/monitors/create endpoint accepts a POST request specifying the monitor type, host, and port. For Postgres, that's a TCP check against port 5432 (or whatever port your instance listens on).
If you'd rather not script this, creating the monitor from your Downdar dashboard is just as quick, pick TCP as the check type and fill in the host and port. Either way, Downdar will attempt a TCP connection to that host and port on its regular check interval and alert you if the connection can't be established.
What a TCP Check Actually Verifies (and Doesn't)
It's worth being precise about what you're getting here, because it's easy to assume a passing check means more than it does. A successful TCP connection to port 5432 confirms that something is listening and accepting connections at the network level. It does not run a query, does not authenticate, and does not confirm the database itself is healthy. A Postgres instance that's accepting TCP connections but stuck, deadlocked, or serving stale data from a lagging replica will still pass a port check.
That's not a flaw in port monitoring, it's just a different layer than application-level health checking. A TCP check catches "the database is unreachable," which is a real and common failure mode, particularly around deploys, firewall changes, and connection pool exhaustion. It won't catch "the database is reachable but broken," which usually needs an application-level check, an actual query, run separately. Many teams run both: a TCP port monitor for basic reachability, plus a scheduled query or health-check endpoint in the application itself for anything deeper. If you want that second layer through Downdar too, an HTTP monitor against a /health endpoint that runs a lightweight query is a reasonable way to add it.
Configuring Alerts
By default, a new monitor alerts through whatever channel is set as your account default. To route this specific monitor to a dedicated channel, say, a database-specific Slack channel your infra team actually watches, pass alert_channel_keys when creating it:
A database going unreachable is usually urgent, so it's worth double-checking this monitor is actually wired into a channel someone monitors in real time, not just email that gets checked once a day.
Checking Monitor Status Programmatically
To pull a monitor's current state into your own tooling, the /api/v1/monitors/status endpoint returns just the essentials.
A Note on Exposing Postgres to Monitoring Traffic
If your database currently isn't reachable from outside your private network, opening port 5432 to the wider internet just so it can be monitored isn't a good trade. Postgres has been targeted by scanning and credential-stuffing traffic for years, and a monitoring check doesn't need broad exposure to do its job, it just needs to reach the port from Downdar's checkpoints specifically.
The safer approach is to allowlist Downdar's checkpoint IP ranges in your firewall or security group rules, rather than opening the port to all traffic. Check your Downdar account or support documentation for the current list of checkpoint IPs to allow. If your infrastructure doesn't support IP allowlisting easily, a VPN or private network path between Downdar and your database isn't something this kind of external check can use, in that case, an internal health-check endpoint monitored over HTTP, sitting behind your existing network boundary, is usually a better fit than exposing the database port directly.
Get Started
Set up the TCP monitor first, since it takes a minute and catches the most common failure mode. Add an application-level health check alongside it once you've decided how deep you want that second layer to go.