TCP Monitoring: What It Tells You That HTTP Checks Cannot

Most teams start monitoring with HTTP checks, and for user-facing apps that is the right first move. An HTTP check asks for a page or API response and tells you whether the path a user cares about is answering. The gap shows up when something underneath that path fails without taking the HTTP layer down with it.

Your API can keep returning 200 while PostgreSQL on port 5432 stops accepting connections from a secondary region. Redis can refuse new clients while the web tier still serves cached pages for a while. A bastion host can lose SSH on port 22 while every public URL stays green. HTTP monitoring will not see those failures, because those services never spoke HTTP in the first place.

TCP monitoring fills that gap.

What a TCP check actually does

A TCP health check attempts to open a TCP connection to a specified host and port. If the three-way handshake completes, the check passes. If the connection is refused, times out, or never completes, the check fails.

That is the whole probe. There is no HTTP request. There is no query. There is no login. The check stops at the transport layer and answers one question. Is something listening here and willing to accept a connection from this network path right now?

How it differs from HTTP monitoring

An HTTP check also opens a TCP connection, then it goes further. It sends an HTTP request, waits for a response, and evaluates status codes, latency, and sometimes body content. That makes HTTP checks a better model of user experience for websites and APIs.

A TCP check intentionally stops earlier. It does not know whether PostgreSQL can run SELECT 1. It does not know whether your gRPC service returns the right protobuf. It only knows the port accepted the connection.

That narrower signal is useful. When you need to know if a dependency is reachable at all, application-layer detail can hide the outage or arrive too late. TCP fails fast on a closed or unreachable port.

If you want the broader map of check types, our overview of HTTP, TCP, DNS, and SSL checks covers how they fit together. This post stays on TCP.

Six cases where TCP is the right tool

Databases. PostgreSQL on 5432, MySQL on 3306, and similar listeners do not expose a useful public HTTP surface. A TCP check from your monitoring regions is often the simplest external signal that the database port is reachable.

Mail servers. SMTP on 25 or 587, IMAP on 993, and related ports are classic TCP monitors. If outbound mail is part of your product or your incident path, waiting for users to report missing messages is a slow detection strategy.

Game servers and custom TCP services. Many game stacks and proprietary protocols listen on custom TCP ports. HTTP checks have nothing to talk to. TCP checks do.

Service mesh and gRPC backends. Internal microservices that speak gRPC or raw TCP will not answer an HTTP monitor aimed at the wrong protocol. Checking the port from a place that should reach it catches network and process failures early.

SSH and management access. Port 22 on bastion hosts and jump boxes is not a user feature, but it is an operational dependency. When SSH is unreachable, your incident response itself is impaired. TCP monitoring on those ports is cheap insurance.

Redis, Valkey, and other cache listeners. Port 6379 does not speak HTTP. A cache outage can degrade the app in ways that look like "slowness" long before a clean HTTP failure appears. TCP tells you the listener disappeared.

The pattern is the same in every case. If the service uses TCP and does not offer an HTTP health endpoint you trust, monitor the port.

What TCP monitoring does not tell you

A green TCP check is not a green service.

PostgreSQL can accept connections and still be in recovery, rejecting writes, or stuck behind lock contention. Redis can accept a TCP connection and still be maxed on memory or returning errors to clients. A process can bind the port and make no progress on real work.

TCP confirms reachability at the transport layer. It does not replace query-level checks, synthetic transactions, or application metrics. Use it as a dependency signal, not as proof that business logic is healthy.

When to use TCP, and when to combine it with HTTP

Use TCP alone when there is no honest HTTP endpoint to hit. Databases, mail, SSH, and many internal ports fall here.

Combine TCP and HTTP when you have a user-facing application that depends on non-HTTP infrastructure. HTTP watches what users hit. TCP watches the dependencies that make that user path possible. A failure on either side is an incident signal. A failure on the dependency side often explains the HTTP symptoms a few minutes later.

For APAC products, run those dependency checks from the regions your app actually uses. A database that accepts connections from your app subnet in Singapore but not from a monitor in Europe may still be fine for users. A database that fails from Singapore, Tokyo, and Sydney is a different story.

Example configuration

Suppose your API in ap-southeast-1 depends on a PostgreSQL primary that should accept connections on port 5432. You already have HTTP monitors on the API. Add a TCP monitor for the database dependency.

A practical setup looks like this.

• Check type. TCP
• Host. db.payments.internal.example.com (or the reachable hostname your monitors can resolve)
• Port. 5432
• Interval. 60 seconds
• Regions. Singapore, Tokyo, Sydney
• Alert when. The check fails from at least two regions, to avoid paging on a single probe path blip

In Vigiles, that is a TCP monitor on the workspace, pointed at the port, with multi-region confirmation before the page fires. Keep the HTTP monitors on the API. The TCP monitor is there so a dependency failure does not have to become a cascade of 500s before anyone notices.

Cover the ports your HTTP checks cannot see

HTTP monitoring answers the user-facing question. TCP monitoring answers the dependency question for everything that never spoke HTTP. Most production stacks need both.

If you are already watching pages and APIs, list the TCP ports your app cannot live without, then put checks on those ports from the regions that matter. The outage you catch before the HTTP layer turns red is the one that pays for the extra monitors.