Port Monitoring Explained: Protect Your Databases, Mail Servers, and More

When people think about uptime monitoring, they think about websites. But your infrastructure is much more than a web server. What about your database? Your Redis cache? Your SMTP server? Your FTP service?

These services don't speak HTTP. They can't be monitored with a standard web check. That's where port monitoring comes in.

What Port Monitoring Does

Port monitoring checks whether a specific TCP port on a host is open and accepting connections. It's simple but powerful:

1. Attempt to establish a TCP connection to host:port
2. If the connection succeeds within the timeout, the service is up
3. If the connection is refused or times out, the service is down

No HTTP. No HTTPS. Just a raw TCP handshake.

What You Should Port Monitor

Databases

Database	Default Port
PostgreSQL	5432
MySQL/MariaDB	3306
MongoDB	27017
Redis	6379
Elasticsearch	9200

Your database going down is often the root cause of application failures. Monitoring the port catches it directly rather than inferring it from application errors.

Mail Servers

Service	Default Port
SMTP	25, 587
IMAP	143, 993
POP3	110, 995

If your transactional email stops working, you might not notice for hours — password resets, order confirmations, and magic link logins all silently fail.

Other Critical Services

Service	Default Port
SSH	22
FTP/SFTP	21, 22
DNS	53
RabbitMQ	5672
Docker API	2376
Kubernetes API	6443

When Port Monitoring Beats HTTP Monitoring

Scenario 1: Database Failure

Your web application returns a generic 500 error because the database is unreachable. HTTP monitoring tells you the app is broken. Port monitoring tells you why — PostgreSQL on port 5432 is down.

Scenario 2: Firewall Changes

A firewall rule change accidentally blocks port 6379 (Redis). Your application still runs but is now extremely slow because every cache miss hits the database. Port monitoring catches this immediately.

Scenario 3: Service Crash

Your message queue (RabbitMQ) crashes at 2 AM. Messages start piling up. The web application still works, but background jobs stop processing. Without port monitoring on 5672, you might not notice until morning.

Setting Up Port Monitoring

Step 1: Inventory Your Services

List every service that listens on a port in your infrastructure. Don't forget internal services that aren't publicly accessible.

Step 2: Determine Access

Port monitoring requires network access to the target port. For internal services, you may need to:

• Monitor from within your VPC/network
• Open specific firewall rules for your monitoring service
• Use an internal monitoring agent

Step 3: Set Appropriate Timeouts

Different services have different acceptable connection times:

• Local services: 1-2 second timeout
• Remote services: 5-10 second timeout
• Services behind VPN: 10-15 second timeout

Step 4: Configure Alerts

Port failures are almost always significant. Unlike HTTP checks where a brief timeout might be a blip, a closed port usually means the service has crashed or a network change has occurred.

Recommendation: Alert after 2 consecutive failures with a 30-second check interval.

Combining Port Monitoring with Other Checks

The best monitoring strategy uses multiple check types together:

1. Port monitoring — Is the service accepting connections?
2. HTTP monitoring — Is the application responding correctly?
3. Keyword monitoring — Is the content correct?
4. Response time monitoring — Is it fast enough?

Each layer catches failures that others miss. Together, they give you comprehensive coverage.

The 5-Minute Setup

1. Add port monitors for your database, cache, and mail server
2. Set check interval to 60 seconds
3. Set timeout to 5 seconds
4. Alert via Slack + SMS after 2 failures
5. Done

Five minutes now could save you hours of debugging later when you immediately know which service went down instead of guessing.