TCP Port Monitoring: How It Works and When to Use It

TCP port monitoring checks whether a specific port on a server is open and accepting connections. It's more useful than ICMP ping (which only checks network reachability) but less comprehensive than HTTP monitoring (which validates the full application response). Understanding when TCP monitoring is the right tool requires understanding what the TCP handshake tells you — and what it doesn't.

How TCP Monitoring Works

A TCP monitor performs a simplified version of the TCP three-way handshake:

Monitor → SYN packet → Your server
Monitor ← SYN-ACK ← Your server  (port is open, service is listening)
Monitor → RST (resets connection)

Result: Port is open and accepting connections

If the server doesn't respond or responds with RST (connection refused), the port check fails.

Unlike ICMP ping, TCP port monitoring confirms that a specific service is listening on a specific port — not just that the machine is alive. Unlike HTTP monitoring, it doesn't verify that the service is responding correctly, just that it's accepting connections.

When to Use TCP Monitoring

TCP monitoring is most useful for non-HTTP services where HTTP monitoring isn't applicable:

| Service | Protocol | Default Port | Use TCP Monitoring? | |---------|----------|-------------|---------------------| | MySQL/MariaDB | TCP | 3306 | Yes | | PostgreSQL | TCP | 5432 | Yes | | Redis | TCP | 6379 | Yes | | SMTP (email) | TCP | 25, 587 | Yes | | SSH | TCP | 22 | Yes (verify accessibility) | | FTP | TCP | 21 | Yes (if used) | | LDAP | TCP | 389 | Yes (directory services) | | Custom TCP services | TCP | Varies | Yes | | HTTP services | HTTP | 80, 443 | No — use HTTP monitoring |

For HTTP and HTTPS services, always use HTTP monitoring instead of TCP. HTTP monitoring provides a superset of what TCP monitoring tells you — if HTTP monitoring passes, the TCP connection is also working. The reverse isn't true.

TCP Monitoring vs ICMP Ping vs HTTP

| Aspect | ICMP Ping | TCP Port Check | HTTP Check | |--------|-----------|----------------|-----------| | Checks network reachability | Yes | Yes | Yes | | Checks service is listening | No | Yes | Yes | | Checks HTTP response code | No | No | Yes | | Checks response content | No | No | Yes | | Works with firewalled ports | Limited | Yes (if open) | Yes | | Overhead | Minimal | Minimal | Medium | | Requires HTTP | No | No | Yes |

Practical Use Cases for TCP Monitoring

Database Port Monitoring

Your application servers can't function without database connectivity. TCP monitoring on port 5432 (PostgreSQL) or 3306 (MySQL) confirms the database is accepting connections.

Important caveat: TCP monitoring on a database port confirms the port is open, not that the database is healthy, queries are executing, or connections are succeeding. Use a dedicated database health endpoint via HTTP for deeper validation.

When TCP database monitoring is valuable:

• Quick check that the database process is running
• Firewall rule validation (confirming ports are accessible from monitoring locations)
• Detecting when database process crashes but server is still up

Mail Server Monitoring

SMTP servers use TCP ports 25, 465, or 587. TCP monitoring confirms your mail server is accepting connections, which is the first requirement for email delivery.

monitor_type: tcp
host: mail.yourcompany.com
port: 587
check_interval: 5 minutes
timeout: 10 seconds

Redis/Cache Monitoring

Redis running on port 6379. TCP monitoring confirms the cache service is available. Combined with an HTTP health check endpoint that validates cache response, you get comprehensive cache monitoring.

Custom Application Ports

Applications that serve on non-standard ports (game servers, custom protocols, internal services) where HTTP monitoring isn't applicable.

Firewall Rule Verification

After network configuration changes, TCP monitoring from multiple geographic locations confirms firewall rules are correctly applied — ports that should be open are open, and the change propagated globally.

Configuring TCP Monitoring in AzMonitor

TCP monitor configuration in AzMonitor:

monitor_type: tcp
host: db.yourapp.com  # or IP address
port: 5432
check_interval: 1m
timeout: 10s
locations:
  - us-east
  - eu-west
alert_on_failure: true
consecutive_failures_before_alert: 2

Key configuration parameters:

• Timeout: How long to wait for the TCP connection to establish. Set based on expected network latency to your server. 5-10 seconds is typical.
• Consecutive failures: Require 2+ failures before alerting to avoid false positives from transient network issues.
• Multiple locations: Run from multiple locations to distinguish server failures from network path failures.

TCP Monitoring Limitations

Doesn't validate service health: A port being open doesn't mean the service is functioning correctly. A database with a locked table, an SMTP server rejecting all messages due to misconfiguration, or a Redis server out of memory — all would pass a TCP port check.

Doesn't validate SSL: TCP monitoring doesn't validate SSL/TLS certificates. Use HTTP monitoring with SSL validation for HTTPS services.

May be blocked by firewalls: Some firewalls silently drop TCP connection attempts (rather than returning RST), causing TCP checks to time out. This can cause false positive alerts if monitoring nodes have restricted access.

Rate limiting and connection limits: Repeated TCP connections to some services (especially security-conscious ones) may trigger rate limiting or be interpreted as a port scan.

Building a Complete TCP Monitoring Strategy

TCP monitoring works best as part of a layered monitoring approach:

1. External HTTP monitoring — For all web-accessible services (AzMonitor's primary check type)
2. TCP port monitoring — For non-HTTP services (databases, mail, custom services)
3. Application health checks — Deep validation via dedicated health endpoints
4. Infrastructure monitoring — CPU, memory, disk from server-side agents

AzMonitor supports TCP monitoring alongside HTTP, DNS, and SSL checks, letting you cover your entire infrastructure from a single platform. Configure your first TCP monitor in minutes.

Related: see our advanced monitoring techniques guide for how TCP monitoring fits into a comprehensive monitoring stack.