TCP Monitoring Explained: Databases, Mail Servers, and Beyond HTTP

HTTP monitoring covers your websites and APIs. But what about your PostgreSQL database? Your Redis cache? Your SMTP mail server? Your custom microservice running on port 8432?

These services don't speak HTTP. They use raw TCP connections. And they go down just as often as your web servers — sometimes more.

What TCP monitoring does

A TCP monitor does exactly what your application does when it connects to a service: it opens a TCP connection to a specific host and port. If the connection succeeds within the timeout window, the service is up. If it refuses the connection or times out, the service is down.

This is the fundamental health check. Before your app can query a database, send an email, or talk to a cache, it has to establish a TCP connection. If that connection fails, nothing else matters.

HTTP vs TCP vs Ping: choosing the right check

Each monitoring type answers a different question:

Ping (ICMP) — "Is the machine reachable on the network?" This tells you the host is powered on and has network connectivity. It does not tell you whether any specific service is running.

TCP — "Is this service accepting connections on this port?" This tells you the process is running and listening. A database that accepts connections is fundamentally operational. A database that refuses connections is broken regardless of what ping says.

HTTP — "Is this web service responding correctly?" This tells you the application layer is working. It can check response codes, measure page load times, and verify content. But it only works for HTTP/HTTPS services.

When to use TCP:

• Databases (PostgreSQL, MySQL, MongoDB)
• Caches (Redis, Memcached)
• Mail servers (SMTP on port 25/587, IMAP on 993)
• Message queues (RabbitMQ, Kafka)
• Game servers (as a basic check)
• Custom internal services on arbitrary ports
• Any service that doesn't expose an HTTP endpoint

Common TCP monitoring use cases

Database monitoring

Your database is probably the most critical dependency in your stack. If it goes down, everything goes down.

Monitor these ports:

• PostgreSQL — port 5432
• MySQL/MariaDB — port 3306
• MongoDB — port 27017
• Redis — port 6379

A TCP check confirms the database process is running and accepting connections. It won't tell you if a specific query is slow, but it will immediately catch a crashed process, connection limit exhaustion, or a failed restart.

Mail server monitoring

Email delivery is often treated as "fire and forget" — you send an email and assume it arrives. But if your SMTP server goes down, emails queue up silently and your customers stop getting password resets, order confirmations, and notifications.

• SMTP — port 25 (server-to-server) or 587 (submission)
• IMAP — port 993 (TLS)
• POP3 — port 995 (TLS)

Cache and queue monitoring

When Redis goes down, your app might not crash immediately. It might just get very slow as every cache miss hits the database directly. By the time someone notices the slowdown, your database might be overwhelmed too.

Similarly, a crashed message queue doesn't always produce errors — messages just stop being processed. Monitoring the TCP port catches the crash immediately, not after a user reports that their job has been "processing" for an hour.

Internal services

Most production architectures have internal services that don't face the internet. These are often the last to get monitoring because they're "behind the firewall" and "should be fine." They're not always fine.

If you have services communicating over TCP on internal ports, monitor them. The ones you think are most reliable are usually the ones with the worst outage response times — because nobody notices when they fail.

Setting up TCP monitoring in PoppaPing

1. Add a new monitor and select "TCP" as the monitor type
2. Enter the host and port — for example, db.yourcompany.com and port 5432
3. Set the check interval — 1 minute is good for critical infrastructure; 5 minutes for secondary services
4. Configure alerts — for database and cache monitoring, PagerDuty or OpsGenie integration is recommended since these are infrastructure-level incidents
5. Enable multi-region checks — confirms the service is actually down from multiple vantage points, not just unreachable from one

Monitoring internal services from outside

A common question: "My database isn't exposed to the internet. How do I monitor the TCP port?"

A few approaches:

Don't expose it directly. Instead, create a lightweight HTTP health check endpoint in your application that verifies the database connection internally and exposes the result on a public endpoint. Then use HTTP monitoring on that endpoint.

Monitor what you can reach. If your app server is public, monitor the app's HTTP endpoint. If the database goes down, the app will start returning errors and your HTTP check will catch it.

Use the port that IS exposed. Your web application is likely on port 443. A TCP check on port 443 won't tell you specifically about the database, but it will catch total host failures.

The point is: monitor every layer you can reach directly, and use the application layer to infer the health of things you can't reach.

Best practices

Monitor connection time, not just success. A TCP connection that takes 5 seconds to establish is almost as bad as one that fails. PoppaPing tracks response time for every TCP check, so you can spot degradation before it becomes an outage.

Set different intervals for different criticality. Your primary database needs 30-second or 1-minute checks. A secondary reporting database that runs batch jobs might be fine at 5 minutes.

Alert the right people. Database outages need infrastructure/DevOps attention. Don't send these to a general channel — route them to PagerDuty or OpsGenie for on-call escalation.

Pair TCP with HTTP. For services that have both a raw port and an HTTP API (like Elasticsearch on 9200), use both. The TCP check catches process crashes; the HTTP check catches application-level issues. Together, they cover more failure modes.