TCP Port Monitoring Explained: What It Is and Why HTTP Checks Miss Half Your Stack (2026 Guide)

Most teams set up uptime monitoring by adding their main application URL to an HTTP check. The dashboard turns green. The team feels covered.

But HTTP monitoring only covers HTTP. Your PostgreSQL database, Redis cache, SSH access, SMTP server, and any custom TCP service your application depends on are invisible to an HTTP check. When your database port closes — due to a misconfiguration, a runaway connection pool exhausting the listener, a firewall rule change — your HTTP check may still return 200 while your application is degrading in the background, failing to serve requests that depend on database reads.

TCP port monitoring covers the gap. This guide explains what it is, why it matters, and how to use it alongside HTTP checks for complete uptime coverage.

What Is TCP Port Monitoring?

TCP port monitoring is an availability check that verifies a specific TCP port on a host is accepting connections. Instead of sending an HTTP request and checking the response body, a TCP monitor opens a TCP connection to the target host and port. If the connection is successfully established (TCP three-way handshake completes), the check passes. If the connection is refused or times out, the check fails and an alert is triggered.

This means TCP monitoring works for any protocol that runs over TCP — not just HTTP and HTTPS. Databases, SSH servers, mail servers, Redis, custom game servers, private API ports, message queues, and any other TCP-based service can be monitored.

TCP port monitoring does not validate what the service is doing. It validates that the service is accepting connections. A PostgreSQL database that accepts connections but has a runaway query blocking all reads would pass a TCP port check. But a PostgreSQL database whose listener has crashed or whose port is blocked by a firewall would fail the TCP check — and that is precisely the failure class TCP monitoring is designed to detect.

Why HTTP Checks Miss Critical Failures

Consider a typical web application stack:

[Browser] → [CDN / Load Balancer] → [App Server] → [PostgreSQL :5432]
                                                  → [Redis :6379]
                                                  → [SMTP :587]

An HTTP check on your main URL only verifies the path through the CDN and load balancer to your app server's HTTP listener. It says nothing about whether:

PostgreSQL is accepting connections on port 5432
Redis is accepting connections on port 6379
Your SMTP relay is accepting mail submissions on port 587
Your SSH server is accessible on port 22 (for remote management)

A PostgreSQL crash — or a firewall rule inadvertently blocking port 5432 — would cause your application to throw database connection errors. Depending on your application's error handling, the HTTP response might still return 500 errors rather than timeouts, which could trigger your HTTP monitor. Or it might return 200 with empty data, degraded functionality, or cached results — and your HTTP check would not fire at all.

TCP monitoring catches this specific failure class: a dependent service's port is closed or unreachable, even when the primary HTTP endpoint is still nominally responding.

Common Ports to Monitor

| Service | Default Port | Why It Matters | |---|---|---| | HTTP | 80 | Basic web traffic; often redirects to HTTPS | | HTTPS | 443 | Primary encrypted web endpoint | | SSH | 22 | Remote server access; if this closes, you cannot remediate manually | | PostgreSQL | 5432 | Primary relational database for most SaaS stacks | | MySQL / MariaDB | 3306 | Alternative relational database | | Redis | 6379 | Cache, session store, message broker — often a hidden dependency | | MongoDB | 27017 | Document database | | SMTP | 25 / 587 | Mail submission; if closed, your application cannot send email | | IMAP / POP3 | 143 / 993 / 110 | Inbound mail reception | | RabbitMQ | 5672 | Message queue; often a dependency for async job processing | | Elasticsearch | 9200 | Search and log indexing | | Kafka | 9092 | High-throughput event streaming | | DNS | 53 | Name resolution; if your internal DNS closes, everything breaks |

You do not need to monitor every port on this list. Start with the ports your application actually depends on in production.

The SSH Port Use Case: Why It Deserves Its Own Monitor

Port 22 (SSH) is a monitoring edge case worth calling out. SSH access is how your team remediates server issues manually. If a firewall rule change or a failing SSH daemon closes port 22, you may lose the ability to SSH into the affected server to fix the underlying problem.

This means a closed SSH port turns a recoverable situation into a crisis requiring console or OOB access, a support ticket to your cloud provider, or an infrastructure automation runbook that may not exist.

Monitoring port 22 and alerting immediately when it closes gives you the window to restore access before the problem compounds. This is especially important for VPS environments where console access is less convenient than cloud providers with web-based serial consoles.

Database Availability Monitoring

Databases are the most common use case for TCP port monitoring in SaaS environments. The typical failure modes that TCP monitoring catches:

Port listener crash: The database process crashes or is killed, closing the listener port. Your HTTP application returns errors. TCP monitoring detects the closed port within the check interval.

Firewall rule change: A security group update, iptables change, or cloud firewall rule blocks external access to the database port. If your application server and database are on the same network, internal traffic might still flow — but a TCP check from an external probe detects the blocked external port.

Connection pool exhaustion causing listener backlog overflow: Under extreme load, the TCP listener's backlog queue fills and new connections are refused. TCP monitoring detects this as a connection refusal.

Database service restart during deployment: A zero-downtime deployment that actually causes a brief service restart can be detected with short-interval TCP checks before users report it.

TCP Port Monitoring vs. HTTP Monitoring: Complementary Coverage

| What It Checks | HTTP Monitoring | TCP Port Monitoring | |---|---|---| | URL returns expected status code | Yes | No | | Response body contains expected keyword | Yes | No | | SSL certificate is valid | Yes (for HTTPS) | No | | Port is accepting TCP connections | No | Yes | | Database port is open | No | Yes | | SSH access available | No | Yes | | Custom service port available | No | Yes | | Response content is correct | Yes | No |

The right monitoring posture uses both. HTTP checks validate that your application is returning correct responses. TCP checks validate that the dependent services your application relies on are accepting connections.

Setting Up TCP Port Monitoring with Vigilmon

Adding a TCP monitor in Vigilmon takes under a minute:

Log in to vigilmon.online and click Add Monitor.
Select TCP as the monitor type.
Enter the hostname and port — for example, db.yourapp.com on port 5432.
Set the check interval — 1 minute on the free tier, 30 seconds on paid plans.
Configure alerts — Slack, email, or webhook. Vigilmon's multi-region consensus logic means a TCP alert only fires when multiple geographic probes independently confirm the port is closed, eliminating transient network path false positives.

The TCP monitor appears on your dashboard and status page alongside your HTTP and SSL monitors. Recovery is automatic — when the port comes back up, the monitor turns green and a recovery alert fires.

Multi-Region TCP Monitoring: Why It Matters

A TCP port that is unreachable from one probe location might be perfectly reachable from all others. A routing anomaly between one probe's network and your server can cause a false alarm.

Vigilmon's multi-region consensus approach applies to TCP monitors the same way it applies to HTTP monitors: before firing an alert, probes from multiple geographic regions must independently fail to connect. This filters single-probe transient network issues and ensures that a TCP alert represents a real, widespread service disruption rather than a network path anomaly affecting one probe.

What TCP Monitoring Does Not Cover

TCP port monitoring verifies connection acceptance. It does not verify:

What the service does after accepting the connection
Whether queries execute correctly
Whether the data returned is valid
SSL certificate validity (use SSL certificate monitors for this)
Response time within acceptable bounds (use HTTP response time monitoring for this)

For database query validation, you need application-level health checks or synthetic transaction monitoring. TCP monitoring is the first gate: is the port even open? If this gate fails, nothing else matters. Fix the open-port issue first, then investigate deeper.

Conclusion

HTTP monitoring covers one failure surface: is your URL returning the right response? TCP port monitoring covers the failure surface beneath it: are the services your application depends on even accepting connections?

A Redis that is not listening on 6379, a PostgreSQL that has closed its port, an SSH daemon that has stopped — these failures are invisible to HTTP monitoring and highly visible to TCP monitoring. Adding TCP checks alongside HTTP and SSL monitors gives you a complete picture of whether your stack is actually up, not just whether your load balancer's front page is responding.

Start TCP port monitoring for free at vigilmon.online — HTTP, TCP, SSL, and heartbeat monitors in one dashboard, multi-region consensus alerting, customer-facing status page, and Slack alerts included. No credit card required.

Tags: #monitoring #devops #tcp #uptime #database #sre #networking #backend