Port Monitoring: Check TCP and UDP Services
Port monitoring tells you a listener answered on host and port. Here is what that proves, what it does not, and which ports deserve a check.
Port monitoring is the practice of checking, on a schedule, that a specific TCP or UDP port on a host still accepts connections and answers in the expected time. It is how you watch a database, a mail server or a game backend without an HTTP endpoint to hit. The term is overloaded, so it helps to say which kind you mean before anyone opens a config file.
Three different things called port monitoring
Switch port mirroring, serial port capture and service port checking are all called the same thing. Cisco's SPAN and RSPAN features copy traffic from one switch interface to another for analysis. Serial tools record bytes crossing a COM port on a workstation. Neither has anything to do with the third sense, which is the one this post covers.
| Sense | What it watches | Typical tool |
|---|---|---|
| Switch mirroring | traffic copied off a physical interface | SPAN, RSPAN, a packet analyser |
| Serial capture | bytes on a COM or tty device | a desktop serial monitor |
| Service port checking | whether a listener answers on host:port | an external uptime checker |
Service port monitoring is the cheapest of the three to run and the easiest to misread, which is why the next section matters more than the setup steps.
What does an open port actually prove?
Less than people assume. A successful TCP handshake proves that something accepted a connection on that host and port within your timeout. It does not prove the process behind it is healthy, that it can reach its own database, or that it will answer a real query.
A Postgres instance with an exhausted connection pool still completes the handshake. So does a message broker that has stopped acking, and so does a proxy in front of a dead backend. The check is a liveness signal at the transport layer, and treating it as a readiness signal is the classic mistake.
That is a limitation of the technique rather than of any particular product. Confirming the protocol above the socket needs either a protocol-aware check or something running inside the process, and an external probe on its own cannot see either. Pair the port check with an application-level health check endpoint when the service has one.
Which ports are worth watching from outside
Only the ones a user or a partner system genuinely reaches. Everything else belongs behind a firewall, and a port that answers the public internet when it should not is a finding rather than a metric.
| Port | Service | Worth an external check? |
|---|---|---|
| 22 | SSH | only if remote access is contractual |
| 25, 587 | SMTP | yes, mail failures are silent otherwise |
| 53 | DNS | yes, and check UDP and TCP separately |
| 443 | HTTPS | prefer a full HTTP check with assertions |
| 3306, 5432 | MySQL, Postgres | only from a trusted source IP |
| 6379 | Redis | almost never, this should not be public |
The IANA service name registry is the reference for anything unusual, and it is worth checking before you assume a number means what you remember.
The rule we apply is simple. If a human or a partner system connects to it, watch it. If only your own hosts connect to it, watch it from inside or not at all. An external probe reaching a private port is a security finding before it is a monitoring result.
For port 443 specifically, a plain connection test wastes a monitor slot. An HTTP check returns the status code, the body and the full timing waterfall for the same effort.
The UDP problem
UDP is connectionless, so there is no handshake to succeed. A datagram sent to a closed port usually produces an ICMP port-unreachable response, and a datagram sent to an open port usually produces nothing at all. Silence therefore means either healthy or dropped, and you cannot tell which from the transport layer alone.
The practical answer is to send a payload the service must reply to. A DNS resolver gets a real query and the answer is validated. A game server gets its status packet and the reply is parsed. Without a reply to inspect, a UDP check can only tell you that a datagram left the probe.
Treat a silent UDP result as unknown rather than healthy. We prefer to alert on a run of consecutive silences rather than a single one. Pairing the check with a TCP check on the same service helps, and DNS is the obvious case, since resolvers answer on both transports.
Checkmk's guide makes the related point that port checks are a second layer beside host metrics, not a replacement for them. That holds doubly over UDP, where a healthy result and a dropped packet look the same.
Setting up TCP port monitoring
Uptime Room has tcp and udp among its ten monitor types. A port check is first class here rather than an HTTP check in disguise. The payload is short:
curl -X POST https://uptimeroom.com/api/v1/monitors \
-H "Authorization: Bearer urm_live_..." \
-H "Content-Type: application/json" \
-d '{
"name": "primary postgres",
"type": "tcp",
"target": "db.example.com",
"port": 5432,
"intervalSec": 60
}'
Three settings decide whether tcp port monitoring is useful or annoying. The interval sets how fast you learn, the confirmation rule decides whether one failure pages anyone, and the source regions decide what "reachable" even means.
That last one bites hardest with databases. If the port is open only to an allowlist, every probe region you enable needs its egress IP on that list. Otherwise the check reports a failure that is really a firewall rule.
Six regions are available as of September 2026 and their addresses are published on the probe IPs page. We tested this against a Postgres instance allowlisted to two regions. The third region reported a connection timeout that looked exactly like a real outage, which cost an hour before anyone checked the firewall.
How this compares to the free options
UptimeRobot's own page says port monitoring is included free with automatic uptime checks (UptimeRobot, as of September 2026). That is a fair offer and worth knowing about. The difference worth asking about is not the price of the check but what happens on a single failed probe.
A one-region checker has to choose between paging fast and paging accurately. Confirmation from a second region removes the choice. It matters more for ports than for HTTP, because packet loss on one path looks identical to a dead listener. The mechanism is described in cross-region quorum confirmation.
Common mistakes
Monitoring 443 with a socket test. The port answers long after the certificate has expired or the application has started returning 500s. Use an HTTP check with a status assertion and let the response-time waterfall tell you which stage is slow.
Alerting on ports nobody depends on. Every monitor you add is a future page at 03:00. If an internal Redis port goes down and no user notices for a day, it does not belong in the alerting path.
Ignoring the timeout. A five-second connect timeout on a database that normally answers in 20 milliseconds hides a serious degradation for four and three quarter seconds. Set the timeout near the real latency, not near the patience threshold.
Good port monitoring is narrow on purpose. Keep a short list of ports users depend on, a tight timeout, and confirmation from a second region before anyone is paged. Layer a protocol-aware check on top wherever the service offers one. You can put the first TCP checks in place on the free plan, which covers 10 monitors at a one-minute interval as of September 2026. Then start free and add the assertions that matter.
FAQ
From a shell, try a TCP connection with netcat or curl against the host and port, and watch whether the handshake completes before your timeout. That is a one-off answer from one location. For anything you depend on, schedule the same test from outside your network so you learn about a failure without running the command yourself.
A socket test will answer the question, but for web ports it is the wrong test. Use an HTTP or HTTPS check instead, because it tells you the status code, the response body and the timing breakdown as well as reachability. Port 443 stays open long after a certificate expires or the application starts returning errors.
On the host itself, ss or lsof will name the process bound to a port. From outside the host you cannot see the process at all, only whether something accepted the connection. That gap is the reason external port checks are a liveness signal rather than a statement about application health.
Those two are the normal web ports and are expected to be reachable, so exposing them is routine when the service behind them is patched and configured correctly. Database and cache ports are a different matter. If a check from an arbitrary region succeeds against Postgres or Redis, treat that as a finding rather than a healthy result.
Related reading
- Cross-Region Quorum: How Confirmation Stops False Alerts - Cross-region quorum means a target is only called down once probes in more than one region agree. Here is the voting rule, its cost and its limits.
- Downtime: What It Means and How to Measure It - Downtime is any period a system is unavailable, but the percentage only means something once you state where you measured from and what counted.
- Golden Signals: The Four SRE Metrics That Matter - Golden signals are latency, traffic, errors and saturation - the four metrics Google's SRE book says to watch when you can only watch four.