Monitoring your data layer: PostgreSQL, Redis, and friends
Your app is only as available as the database and cache behind it — services that speak TCP, not HTTP. Here's how port monitoring watches the data layer HTTP checks can't see.
When people say “the site is down,” the root cause is often one layer deeper: a database refusing connections, a cache that fell over, a connection pool exhausted. These services don’t speak HTTP, so your website monitor can’t see them — until the failure bubbles up as user-facing errors. Port monitoring watches that layer directly.
Why HTTP checks miss the data layer
A website check tells you the front door responds. It says nothing about whether PostgreSQL is accepting connections or Redis is reachable. By the time a datastore problem shows up in an HTTP 500, you’ve lost the head start you’d have had watching the datastore itself. Monitoring the port closes that gap.
What to watch, and on which ports
Port monitoring confirms a TCP service is accepting connections. The usual suspects:
- PostgreSQL (5432), MySQL / MariaDB (3306), SQL Server (1433)
- Redis (6379), Memcached (11211)
- MongoDB (27017), Elasticsearch (9200)
- SMTP (25) for mail, SSH (22) for admin access, and any custom port your service listens on
If it accepts TCP connections, you can watch it.
Connection open ≠ healthy — but it’s a strong signal
Port monitoring confirms the service is listening and accepting connections. That won’t catch a slow query or a corrupt index, but it reliably catches the failures that take a data layer offline: the process crashed, the host is unreachable, the connection pool is exhausted, a firewall rule changed. Pair it with response-time monitoring on your app for the query-level view, and you’ve got both angles.
Cut the false alarms
Databases live behind firewalls and blip under load, so trustworthy alerting matters even more here:
- Confirm from multiple regions before alerting — a single probe’s dropped connection isn’t an outage.
- Use consecutive-failure thresholds so a momentary refusal during a failover doesn’t page anyone.
- Allow-list the probe IP ranges for each region so your firewall doesn’t mistake monitoring for an attack.
The bottom line
Your checkout is only as available as the database behind it. Watching the data layer’s ports gives you a direct, early signal when a datastore stops accepting connections — minutes before it surfaces as user-facing errors. Add it alongside your HTTP and response-time checks for full-stack coverage.
Watch every TCP service. Explore port monitoring →
