TCP Port Monitoring: Beyond HTTP Health Checks

Most uptime monitoring focuses on HTTP. You point a monitor at a URL, it makes a GET request, and checks for a 200 response. That covers your website, your API, and your status page — but it leaves an enormous blind spot: everything that doesn't speak HTTP.

Your PostgreSQL database, Redis cache, SMTP mail server, message broker, or game server — none of these respond to HTTP requests. But all of them can go down. And when they do, your application breaks in ways that HTTP monitoring won't catch until users start reporting errors.

TCP port monitoring fills this gap. Instead of making an HTTP request, a TCP monitor simply tries to establish a TCP connection to a host on a specific port. If the connection succeeds, the service is up. If the connection is refused or times out, the service is down. No HTTP required.

---

How TCP monitoring works

At the network layer, TCP (Transmission Control Protocol) is what most internet services use to communicate. When a client connects to a server, it initiates a TCP handshake: the client sends a SYN packet, the server responds with SYN-ACK, and the client completes the handshake with ACK. If the handshake succeeds, the connection is open and the service is reachable.

A TCP port monitor automates this handshake. It connects to your host on a specified port, attempts the handshake, and reports:

• Connection succeeded — the port is open and accepting connections
• Connection refused — the port is closed or the process isn't listening
• Connection timed out — the host is unreachable, or a firewall is dropping packets

Unlike HTTP monitoring, TCP monitoring doesn't inspect the content of responses — it only checks reachability. That's usually exactly what you need for infrastructure services. You don't need to know if your Redis server is returning the right value; you need to know if it's accepting connections at all.

---

Services worth monitoring with TCP

Any service with a known port is a candidate for TCP monitoring. The most common use cases:

Databases

Database TCP failures are particularly costly. When your PostgreSQL server stops accepting connections, your application typically returns 500 errors for every request that needs data — which is usually all of them. A TCP monitor on port 5432 catches this the moment the connection fails, before your application logs fill up with connection errors.

Message brokers and queues

Background workers and async jobs depend on message brokers. If RabbitMQ (5672) or Kafka (9092) goes down, jobs stop processing but your web frontend may still appear healthy. Users see their requests succeed but nothing actually happens. TCP monitoring on your broker port catches this disconnect early.

Mail servers

If you run your own SMTP server (port 25, 465, or 587), TCP monitoring confirms it's accepting connections. SMTP failures are invisible to HTTP monitoring — your web app works fine, but transactional emails, password resets, and notifications never send.

Custom and internal services

gRPC servers, game servers, custom TCP protocols, internal microservices that don't expose HTTP — all of these are monitorable with TCP checks. If your service listens on a port, TCP monitoring can tell you if that port is open.

---

TCP monitoring vs HTTP monitoring: which to use when

The choice isn't either/or — most production setups need both. Here's a practical guide:

---

What TCP monitoring doesn't tell you

TCP monitoring confirms that a port is accepting connections. It does not tell you whether the service behind that port is healthy or responding correctly. A database that accepts connections but crashes on every query will pass a TCP check. A Redis instance that's out of memory and returning errors will pass a TCP check.

For services that expose HTTP or a queryable API, layer HTTP monitoring on top. For databases, consider application-level health checks: a dedicated health check endpoint in your app that runs a lightweight query (SELECT 1) and returns 200 if it succeeds. Then monitor that HTTP endpoint with PingBase alongside your TCP monitor.

The combination gives you two layers: TCP confirms the database is reachable at the network level; HTTP confirms the application can actually query it.

---

Response time matters too

A TCP connection that succeeds but takes 3 seconds to complete is a warning sign. Normal TCP handshakes complete in milliseconds. Slow TCP connections often indicate:

• Network congestion between your monitoring probe and the host
• The server is overloaded and slow to accept connections
• A firewall or proxy is intercepting and delaying connections
• The host is running out of available file descriptors or connection slots

PingBase records response time for TCP monitors, not just pass/fail status. You can set response time thresholds — alert if connection time exceeds 500ms, for example — to catch degradation before it becomes a full outage.

---

Setting up TCP monitoring in PingBase

Adding a TCP monitor takes about 30 seconds:

1. Create a new monitor and select TCP as the monitor type
2. Enter the hostname or IP address of the host you want to monitor
3. Enter the port number (e.g., 5432 for PostgreSQL)
4. Set your check interval — every 1 minute for critical services
5. Configure alert channels: email, Slack, PagerDuty, webhook, or Telegram

TCP monitors appear on your status page alongside HTTP and SSL monitors. If your database goes down, your status page reflects it — useful for internal status pages shared with your engineering team.

You can also add TCP monitors to monitor groups. Group your database, cache, and message broker monitors together under "Infrastructure" — so at a glance you know whether application-layer problems have an infrastructure root cause.

---

Firewall and network considerations

TCP monitoring from an external probe only works if your host is reachable from the internet on that port. For publicly accessible services (web servers, mail servers) this is fine. For databases and internal services, you typically don't want them internet-accessible — and you shouldn't open firewall rules just to enable monitoring.

Options for monitoring internal services:

• Application health endpoint — expose an HTTP health check endpoint that your application serves from inside the network, which internally checks your database, Redis, etc. Monitor the health endpoint externally via HTTP.
• Heartbeat monitoring — run a lightweight agent inside your network that pings PingBase on a schedule. If PingBase stops receiving heartbeats, it alerts you. The monitoring traffic stays inside your network.
• VPN + monitoring — run your monitoring probe inside a VPN or private network where internal services are accessible.

For most setups, the application health endpoint approach is the cleanest: one HTTP endpoint that aggregates the health of all internal dependencies, monitored externally. TCP monitors complement this for services that are publicly accessible.