What a TCP port check tells you
A TCP port check confirms that a service is listening and accepting connections at a given host and port. Uptime Tracker opens a TCP connection to host:port, and if the connection is refused or times out, the check fails.
That simple test catches a lot:
- The process crashed or was not restarted after a reboot.
- A firewall or security group change blocked the port.
- The host itself is down or unreachable.
- The service is so overloaded it stops accepting new connections.
Common targets include SSH on port 22, database proxies, game servers, MQTT brokers, SIP servers, custom TCP APIs and VPN endpoints that listen on TCP. Each check records connection time, which also gives you a rough view of network latency to the host.
A port check does not prove the application behind the port is healthy. A database can accept connections and still reject every query. Where possible, pair a port monitor with a deeper check: an API monitor on an HTTP health endpoint, or a heartbeat from a script that runs a real query and pings on success.
Monitors must target public addresses; private and internal network addresses are blocked for security. Exposing a database port to the internet just to monitor it is not recommended; use a heartbeat from inside the network instead.
gRPC health checks
On the Team plan, Uptime Tracker can check gRPC services using the standard gRPC health checking protocol, grpc.health.v1, over TLS. Instead of only confirming the port is open, it asks the service itself whether it is serving.
The health protocol is the same one used by load balancers and orchestrators, so many gRPC frameworks already implement it or can add it with a few lines. If your service reports SERVING, the check passes; if it reports anything else or does not respond, the check fails and the usual failure confirmation applies.
Why this is better than a TCP check for gRPC:
- A gRPC server can accept connections while its dependencies are down. A health check lets the service report that.
- TLS is negotiated as part of the check, so certificate problems surface too.
- The result reflects what your clients experience when they make real calls.
Uptime Kuma users can import existing gRPC monitors from a JSON backup; they are mapped automatically along with HTTP, port, ping, DNS and push monitors. See monitoring for developers for more on importing and automating monitors.
SMTP and IMAP mail server checks
On the Team plan, SMTP and IMAP checks confirm that your mail servers are answering correctly and negotiating TLS, without ever logging in or sending a message. They are designed for teams that run their own mail infrastructure or depend on a mail relay.
Each check connects to the server, reads the greeting banner, and verifies TLS, either by upgrading the connection with STARTTLS or by connecting with implicit TLS on the dedicated secure port. If the banner is missing, the server refuses the connection, or the TLS negotiation fails, the check fails.
| Protocol | Common ports | TLS mode |
|---|---|---|
| SMTP submission | 587 | STARTTLS |
| SMTP over TLS | 465 | Implicit TLS |
| IMAP | 143 | STARTTLS |
| IMAP over TLS | 993 | Implicit TLS |
Because these checks never authenticate, you do not need to store mailbox credentials in Uptime Tracker. Combine them with DNS monitoring of your MX and TXT records to catch the other common cause of mail delivery problems: a DNS change that breaks routing or sender authentication.
Set up a port monitor
A TCP port monitor takes under a minute to set up on any plan.
- Sign in and create a new monitor with the type TCP port.
- Enter the public hostname or IP address and the port number, for example
game.example.comand25565. - Choose a check interval: every 5 minutes on Free, 60 seconds on Starter or 30 seconds on Team.
- Pick the alert channels and add a tag so routing rules can treat the monitor appropriately.
- Save, then confirm the first check shows as up with a connection time.
For gRPC, SMTP or IMAP on Team, choose that monitor type instead and enter the host and port.
Group related monitors in a project if you run services for several customers or environments. Projects are available on every plan: 1 on Free, 3 on Starter and 10 on Team. Tags such as database or game make it easy to route port alerts separately from website alerts, for example sending game-server outages to a Discord channel your players can see.
What's included on each plan
TCP port checks are free on every plan; protocol-aware gRPC, SMTP and IMAP checks are part of Team.
| Free | Starter | Team | |
|---|---|---|---|
| TCP port monitors | Yes | Yes | Yes |
| Ping (ICMP) monitors | No | Yes | Yes |
| gRPC health checks over TLS | No | No | Yes |
| SMTP and IMAP banner and TLS checks | No | No | Yes |
| Standard monitors | 2 | 10 | 50 |
| Fastest interval | 5 minutes | 60 seconds | 30 seconds |
For a service or two, TCP checks on Free are enough to know whether something is listening. Upgrade to Starter for 10 monitors, 60-second checks and ping monitors, or to Team when you run gRPC services or your own mail servers and want the protocol itself verified. Team also adds monitor dependencies, so a host outage produces one alert rather than one per port. TCP, gRPC, SMTP and IMAP monitors all count toward the same standard monitor limit.
For host-level reachability, see ping monitoring. All limits are on the pricing page.
