TCP monitoring: keep every service on your server reachable

A server that answers ping can still be useless if the service you need on it has stopped listening. TCP monitoring closes that gap: instead of asking whether the machine is reachable, it asks whether a specific service – HTTPS, SSH, mail, FTP, a database – accepts connections on its port. This guide explains what a TCP port is, how a TCP ping or TCP port check works, which ports are worth monitoring, how to set checks up with standard tools and which settings keep false alarms away.

What is TCP port monitoring?

TCP port monitoring checks the status of Transmission Control Protocol ports on a server to make sure the services behind them are open and listening for incoming connections. A monitor periodically tries to connect to a host and a port number. If the connection succeeds, the service is available; if it is refused, reset or times out, something is wrong – the process may have crashed, a firewall rule may have changed or the server may be overloaded.

Because the check uses the same port real clients use, it reflects the experience of mail clients, SSH sessions, database connections and browsers far better than an ICMP ping. It also works on hosts that block ping entirely, which many cloud servers do by default. That is why TCP checks are often called TCP ping: they answer the reachability question, but at the level of a specific service.

How a TCP check works

Every TCP connection starts with a three-way handshake. The client sends a SYN packet, a listening service answers with SYN-ACK, and the client confirms with ACK. A TCP monitor performs exactly this handshake, measures how long it took and then closes the connection again. A SYN-ACK means the port is open; a reset (RST) means the host is reachable but nothing is listening, which typically shows up as “connection refused”; no answer at all within the timeout usually means a firewall is dropping packets or the host is unreachable.

Simple checks stop after the handshake. More thorough ones send a few bytes and read the response, for example the greeting banner of an SMTP or FTP server, or perform a TLS handshake on port 443 or 465. That adds confidence that the right service is answering rather than something else bound to the port. Either way, the core metrics are the same: up or down, connect time in milliseconds and the history of both.

What is a TCP port?

A TCP port is a number between 0 and 65535 that identifies a specific endpoint on a host. The IP address gets packets to the right machine; the port gets them to the right application on that machine. That is how one server can run a web server, a mail server, SSH and a database at the same time – each listens on its own port, and the operating system routes incoming connections accordingly.

Ports 0 to 1023 are the well-known ports assigned to standard services, 1024 to 49151 are registered ports used by many applications and databases, and the rest are dynamic ports used for the client side of connections. Knowing which port each of your services listens on is the starting point for TCP monitoring: one check per port that matters.

Test a TCP port manually

Before setting up a monitor, confirm the port is reachable from outside. On Linux and macOS, nc -vz -w 5 host port (netcat) tries a connection and reports success or failure within five seconds. On Windows, Test-NetConnection host -Port 443 in PowerShell does the same and prints TcpTestSucceeded. telnet host port still works where it is installed, and nmap -p 22,443,587 host scans several ports at once and shows whether each is open, closed or filtered.

$ nc -vz -w 5 mail.example.com 587
Connection to mail.example.com 587 port [tcp/submission] succeeded!
$ nc -vz -w 5 db.example.com 3306
nc: connect to db.example.com port 3306 (tcp) failed: Connection refused
PS> Test-NetConnection web.example.com -Port 443
TcpTestSucceeded : True

Run these tests from a machine outside your network, because a test from the server itself or from the same LAN bypasses the firewall and routing an external monitor goes through. A port that is open locally but filtered from the internet will look perfectly fine until you test it from the outside.

Check server uptime and track network devices

TCP checks are a reliable way to check server uptime when ICMP is blocked. Pick a port the server always serves – 443 on a web server, 22 on most Linux hosts – and the check doubles as a host availability monitor. Many teams run a ping check and a TCP check side by side: when both fail, the host or network is down; when only the TCP check fails, the machine is alive but the service has stopped.

The same approach works for network devices. Firewalls, VPN gateways, load balancers and managed switches usually expose a management or service port – HTTPS for a web interface, SSH, or the VPN port itself – and a TCP check on that port confirms the device is up and accepting connections. Keep management interfaces restricted to known IP addresses, and allow your monitoring service’s published IPs explicitly rather than opening the port to everyone.

Monitor server response time

Each successful TCP check yields a connect time: how long the handshake took. It mostly reflects network distance and how quickly the server’s operating system accepts connections, so it is a good indicator of network congestion and heavy load. When a server runs out of resources or its connection backlog fills up, connect times climb before connections start failing. Alerting on a connect time well above the usual baseline gives you warning before a full outage.

Keep in mind what connect time does not measure. A database can accept connections instantly and still run every query slowly; a web server can complete the handshake and then take seconds to render a page. For user-facing services, add application-level checks such as HTTP response time on top of TCP connect time.

Set up TCP monitoring in a few steps

Whether you use a hosted uptime service, an open-source system such as Nagios with check_tcp, Zabbix, Icinga, Prometheus with the blackbox exporter or Uptime Kuma, the setup follows the same pattern.

• List each service and its host and port, for example mail.example.com:587 or 203.0.113.10:22
• Create one TCP monitor per service and give it a clear name and a tag to group monitors by server or customer
• Choose an interval of one to five minutes and a timeout that fits the service, often 5 to 30 seconds
• Allow the monitoring IPs through firewalls and security groups on that port
• Require a retry or a second location before alerting to avoid false positives
• Set a connect-time threshold relative to the normal baseline
• Choose notification channels – email at minimum – and recurring reminders for long incidents

Features that make TCP monitoring reliable

A few settings separate a TCP monitor you trust from one you mute. Continuous alerts with threshold and recurrence settings make sure a long outage is not forgotten after the first notification. Maintenance windows pause checks during planned updates and reboots. A custom request timeout prevents false positives when a service is briefly slow to accept connections; up to a minute is reasonable for services that are known to be sluggish under load.

Multi-location checks validate an incident from several geographic locations before alerting, which filters out routing problems on a single path. Incident records with root-cause notes help you spot recurring failures, such as a database that runs out of connections every Monday morning. And shared account access with roles such as admin, read, write or notify-only lets colleagues see monitors and receive alerts without being able to change everything.

Benefits of TCP monitoring

The main benefit is that you maintain the availability of all services, not only the website. Mail, file transfer, remote access and databases fail quietly: nobody notices a stopped IMAP server until users complain they cannot read mail. A TCP check on every important port turns those silent failures into immediate alerts.

It also improves user experience and keeps reviews positive, because problems are fixed before many users hit them, and it lets you get alerts and fix network issues before they spread. When the TCP check fails together with ping, you know to look at the network; when it fails alone, you go straight to the service. That shortens troubleshooting considerably.

• Covers every TCP service: HTTPS, FTP, SMTP, IMAP, POP3, DNS over TCP, SSH, databases
• Works on hosts that block ICMP ping
• Separates host problems from service problems
• Connect-time trends warn about overload before outages

Common TCP monitoring mistakes

The most common mistake is assuming an open port means a healthy service. A process can accept connections while hanging, returning errors or serving stale data. For critical services, add a protocol-level check – an HTTP request, an SMTP banner check or a test query – on top of the TCP check. Another frequent mistake is monitoring from inside the same network, which hides firewall and routing problems that external users experience.

Watch out as well for timeouts that are too short, single-attempt alerts, forgotten IPv6 listeners, and ports that are only open to the monitoring IP while real clients are blocked by a different rule. Finally, do not expose sensitive ports such as databases to the whole internet just to monitor them; restrict access to the monitoring IPs or monitor them from inside the network.

Website monitoring with monitordefend

monitordefend does not offer TCP, port or ping monitoring, so it cannot watch SSH, mail or database ports. It is a hosted website monitor: every five minutes from Germany it requests your homepage over HTTP or HTTPS, confirms a failure with a second attempt, tracks response time and sends email alerts, and it also checks broken links, sitemaps, Google indexing, checkout pages and suspicious changes to your site. For the services behind your website, use a dedicated TCP monitor alongside it.

Frequently asked questions

What is TCP port monitoring?

It is the regular check of TCP ports on a server to confirm that the services behind them are open and listening. A monitor opens a connection to a host and port; a completed handshake means the service is up, a refusal or timeout triggers an alert after confirmation.

What is a TCP port?

A number from 0 to 65535 that identifies an endpoint on a host. The IP address finds the machine, the port finds the application, which lets one server run web, mail, SSH and database services side by side.

What ports can you monitor?

Any TCP port. Common ones are 21 (FTP), 22 (SSH/SFTP), 80 and 443 (HTTP/HTTPS), 53 (DNS over TCP), 110 and 995 (POP3), 143 and 993 (IMAP), 25, 465 and 587 (SMTP), 3306 (MySQL) and 5432 (PostgreSQL).

What is TCP ping?

A reachability test that completes a TCP handshake on a port instead of sending an ICMP echo request. It works on hosts that block ICMP and measures connect time, which makes it a practical replacement for ping on many cloud servers.

What is the difference between TCP monitoring and ping monitoring?

Ping checks whether the host answers on the network; TCP monitoring checks whether a specific service accepts connections on its port. A host can answer ping while a service on it is down.

Does an open TCP port mean the service works?

Not necessarily. It proves the service accepts connections. To confirm correct answers, add a protocol-level check such as an HTTP request or reading the SMTP banner.

Does monitordefend support TCP monitoring?

No. monitordefend monitors websites over HTTP every five minutes from Germany and alerts by email; it has no TCP, port or ping checks.

Related pages

• Port monitoring: watch any port on your server
• Ping monitoring: check that any server or device is reachable
• UDP port monitoring for services that fail quietly
• The All-in-One Website Monitoring Tool
• Website Response Time Monitoring
• SSL certificate checker