TCP Port Monitoring: Why and How to Check Services

What is TCP Port Monitoring?

While HTTP checks are essential for websites and APIs, they can't see the whole picture. Many critical backend services-databases, mail servers, message queues-don't "speak" HTTP. They communicate over other protocols on specific TCP ports.

TCP port monitoring is a type of synthetic check that verifies if a server is accepting connections on a specific port. Think of it like this: an HTTP check knocks on the front door and asks who's there. A TCP port check simply verifies that a specific door (the port) is unlocked and someone is home to open it. It's a foundational check that answers one simple, vital question: "Is my service listening?"

Unlike an HTTP check that expects a 200 OK status code and specific content, a TCP check is simpler. It succeeds if it can establish a basic TCP connection (the "three-way handshake"). If the port is closed, blocked by a firewall, or the service has crashed, the connection fails, and an alert is triggered.

Why You Need Port Monitoring (Beyond HTTP)

Relying solely on HTTP monitoring leaves massive blind spots. Your web server might be running perfectly, serving a 200 OK status code, but if it can't connect to its database, your application is effectively down. Port monitoring closes this gap by checking these non-HTTP dependencies directly.

Here are some common services where TCP port monitoring is critical:

• Databases: Your application's data layer is its foundation.
  • PostgreSQL: Port 5432
  • MySQL / MariaDB: Port 3306
  • Redis: Port 6379 (for caching, sessions, or queues)
  • MongoDB: Port 27017
• Mail Servers: If you run email services, ensuring connectivity is paramount.
  • SMTP: Ports 25, 465 (SMTPS), 587 (Submission)
  • IMAP: Ports 143, 993 (IMAPS)
• Remote Access & File Transfer: Crucial for infrastructure management and data pipelines.
  • SSH: Port 22 (for secure shell access and Git operations)
  • FTP / SFTP: Ports 21 (FTP), 22 (SFTP)
• Internal Microservices: Many internal APIs and services communicate over custom TCP ports without using HTTP.

By monitoring these ports, you can get alerted to a failure in a specific component (e.g., "Redis is down") instead of a generic "the website is broken" alert, leading to a much faster diagnosis.

How to Perform a Manual TCP Port Check

Before setting up automated monitoring, it's useful to know how to check a port manually from the command line. This is great for quick troubleshooting. The two most common tools are telnet and nc (netcat).

Using telnet

telnet is an old-school utility for interacting with remote services. To check a port, run:

# Usage: telnet [hostname] [port]
telnet my-database.internal 5432

• Success: If the port is open, you'll see a message like Trying 10.0.1.5... followed by Connected to my-database.internal. and a blank screen. The service is listening. You can close the connection by typing Ctrl+] then quit.
• Failure (Closed): If the service isn't running on that port, you'll get Connection refused almost instantly.
• Failure (Blocked): If a firewall is blocking the connection, the command will hang for a while and eventually time out with a message like telnet: connect to address 10.0.1.5: Connection timed out.

Using nc (netcat)

netcat is a more modern and powerful networking tool. The -z (zero-I/O mode) and -v (verbose) flags are perfect for port scanning.

# Usage: nc -zv [hostname] [port]
nc -zv my-database.internal 5432

The output is much cleaner than telnet:

• Success: Connection to my-database.internal port 5432 [tcp/postgresql] succeeded!
• Failure: nc: connect to my-database.internal port 5432 (tcp) failed: Connection refused

These manual checks are invaluable for diagnostics, but they aren't a substitute for 24/7 automated monitoring.

Setting Up Automated Port Monitoring

Automated port monitoring ensures you're the first to know when a critical service goes offline, not the last. While you could write a custom script, a dedicated monitoring service provides key advantages like multi-region checks, configurable alert routing, and performance history.

For example, setting up a TCP check in ServerInspector is straightforward. You provide the hostname or IP address, the port number, and choose your check frequency and alert contacts. The service then handles the continuous checks from its global network.

Checklist: Key Services and Ports to Monitor

Use this table as a starting point for building out your TCP monitoring strategy.

Common Pitfalls and Best Practices

When setting up TCP port monitoring, keep these common issues in mind to avoid false alarms and security risks.

• Firewall Configuration: This is the #1 cause of failed port checks. If your monitoring service is external, you must add its probing IP addresses to your firewall's allowlist for the specific ports you want to monitor. A good monitoring service will publish its IP addresses for this purpose.
• Service Binding: A service might be running but only listening on the local loopback interface (localhost or 127.0.0.1). If this is the case, an external check will fail because the service isn't accessible from the outside. The service must be bound to 0.0.0.0 or a specific public/private IP address to be monitored externally.
• Internal vs. External Monitoring: Never expose a sensitive service like a database to the public internet just for monitoring.
  • Best: Monitor internal services from an internal monitoring agent.
  • Good: If using an external service, create very strict firewall rules that only allow access from the monitoring service's specific IPs to the specific port.
• TCP vs. Application Health: A successful TCP check only confirms the service is listening. It doesn't mean the service is healthy. For example, a database might accept a connection but be out of disk space and unable to process queries. For critical services, combine a TCP port check (for liveness) with a deeper application-level health check (for readiness).

Automated monitoring tools like ServerInspector provide a simple, reliable way to implement these checks, giving you a comprehensive view of your entire infrastructure's health, not just the web-facing parts.

Frequently Asked Questions (FAQ)

Q1: Is TCP port monitoring the same as a ping check? A: No. A ping check uses the ICMP protocol to see if a host machine is reachable on the network. A TCP port check goes a step further to verify if a specific application or service is running and accepting connections on that machine. A server can be pingable but have its database service crashed.

Q2: Can I monitor UDP ports? A: UDP is a "connectionless" protocol, which makes reliable open/closed monitoring difficult. Unlike TCP's handshake, sending a UDP packet doesn't guarantee a response unless the application protocol is designed for it (like DNS). For this reason, most uptime monitoring services focus on TCP, as it provides a definitive connection state.

Q3: My TCP port check is failing, but I know the service is running. What's wrong? A: The most common culprit is a firewall blocking the connection between the monitoring probe and your server. Check your cloud provider's security groups, network ACLs, and the server's own firewall (like ufw or iptables). Another possibility is that the service is only bound to localhost.

Q4: How often should I check a TCP port? A: The ideal frequency depends on the criticality of the service. For a production database or a critical API, a 1-minute check interval is standard. For less critical internal tools or development environments, a 5 or 10-minute interval might be sufficient.