Skip to content

Port Monitoring

Check whether UptimeObserver can establish a TCP connection to a specific public port on your server.

Overview

Port monitoring checks TCP connectivity. This is useful for services that don't use HTTP, such as:

  • Database servers (MySQL, PostgreSQL, MongoDB)
  • Mail servers (SMTP, IMAP, POP3)
  • Game servers with a TCP endpoint
  • SSH access
  • Custom TCP services

UptimeObserver reports success when the TCP connection succeeds. It may also read an initial service banner, waiting up to 2 seconds, but a missing or unreadable banner does not fail the check. It does not send an application-specific request, authenticate, or verify that the service can process work.

Port monitor creation form

Configuration Options

Hostname / IP Address

Enter the hostname or IP address of the server you want to monitor:

  • db.example.com — Using a hostname
  • 192.0.2.10 — IPv4 documentation example
  • 2001:db8::1 — Using an IPv6 address

Replace the example addresses with a publicly reachable host. Private LAN addresses are not reachable from UptimeObserver's monitoring servers.

Use Hostnames

Using hostnames instead of IP addresses makes it easier to update server IPs without modifying your monitors.

Port Number

Specify the port number to check (1-65535):

Port Service
21 FTP
22 SSH
23 Telnet
25 SMTP
53 DNS
110 POP3
143 IMAP
443 HTTPS
465 SMTPS
587 SMTP (submission)
993 IMAPS
995 POP3S
3306 MySQL
3389 RDP
5432 PostgreSQL
5672 RabbitMQ
6379 Redis
11211 Memcached
27017 MongoDB

Protocol

Port monitors use TCP only. There is no UDP protocol selector.

UDP-only services

A TCP connection does not test a UDP service on the same port. UDP is connectionless, and merely sending a datagram cannot prove that a service is listening. For DNS, use a DNS monitor to check a real answer. For another UDP-only service, use an external application-level probe that sends a heartbeat only after a valid response, or monitor a supported HTTP health endpoint.

Timeout

Set the maximum time to wait for the TCP connection, in seconds:

The optional banner read can add up to 2 seconds after the connection succeeds. Failure to connect is processed using the Retries threshold.

Common Use Cases

Database Server (MySQL)

Monitor your MySQL database server:

  • Hostname: db.example.com
  • Port: 3306
  • Protocol: TCP
  • Timeout: 10 seconds

Database Server (PostgreSQL)

Monitor your PostgreSQL database:

  • Hostname: postgres.example.com
  • Port: 5432
  • Protocol: TCP
  • Timeout: 10 seconds

Redis Cache

Monitor your Redis instance:

  • Hostname: redis.example.com
  • Port: 6379
  • Protocol: TCP
  • Timeout: 5 seconds

Mail Server (SMTP)

Monitor your outgoing mail server:

  • Hostname: mail.example.com
  • Port: 587
  • Protocol: TCP
  • Timeout: 10 seconds

Mail Server (IMAP)

Monitor your incoming mail server:

  • Hostname: mail.example.com
  • Port: 993
  • Protocol: TCP
  • Timeout: 10 seconds

SSH Access

Monitor SSH availability:

  • Hostname: server.example.com
  • Port: 22
  • Protocol: TCP
  • Timeout: 10 seconds

Game Server

Monitor a game server's TCP endpoint, if it provides one:

  • Hostname: game.example.com
  • Port: 27015
  • Protocol: TCP
  • Timeout: 15 seconds

Do not use this example for a UDP-only game port. A TCP result says nothing about whether its UDP service is healthy.

Custom Application

Monitor a custom service:

  • Hostname: app.example.com
  • Port: 8080
  • Protocol: TCP
  • Timeout: 10 seconds

When to Use Port Monitoring

Instead of HTTP Monitoring

Use port monitoring when your service:

  • Doesn't speak HTTP (databases, mail servers, SSH)
  • Uses a custom protocol
  • Needs basic availability checks without HTTP overhead

Alongside HTTP Monitoring

Use port monitoring together with HTTP monitoring to:

  • Monitor backend services that support your web application
  • Get early warning if database or cache servers go down
  • Monitor services on non-standard ports

For Internal Services

Our monitoring servers must be able to reach the TCP endpoint. For private-only services, run your own health check inside the network and send a heartbeat after success. UptimeObserver does not provide a built-in VPN connection to your network.

Security Considerations

Firewall Configuration

Ensure your firewall allows connections from UptimeObserver's monitoring servers. See Bot Documentation for our IP addresses.

Port Exposure

Security Best Practice

Only expose ports that are necessary. For internal services like databases, consider whether they need to be accessible from the internet.

If your service should only be accessible internally:

  1. Keep it private; do not expose a database solely to enable a port monitor
  2. Run an application-level check inside your network
  3. Send a heartbeat only when that check succeeds

Troubleshooting

Connection Refused

The server actively rejected the connection:

  1. Service not running — Verify the service is started on the server
  2. Wrong port — Confirm the service is listening on the specified port
  3. Firewall blocking — Check firewall rules allow incoming connections

Connection Timeout

No response was received within the timeout period:

  1. Firewall dropping packets — Firewall may be silently dropping connections
  2. Server unreachable — Check network connectivity to the server
  3. Increase timeout — The service may be slow to respond

Host Unreachable

The server could not be reached:

  1. Verify hostname/IP — Ensure the hostname resolves or IP is correct
  2. Check server status — The server may be down or offline
  3. Network issues — There may be routing problems between monitoring locations and your server

Service Running But Monitor Fails

  1. IP restrictions — The service may only accept connections from specific IPs
  2. Rate limiting — The server may be rate-limiting connection attempts
  3. Protocol mismatch — Confirm the endpoint accepts TCP; a UDP-only service cannot be checked with a port monitor

Monitor Is Up but the Service Is Not Working

An accepted TCP connection is not an application health check:

  1. Check the right endpoint — A proxy or load balancer may accept the connection even when its backend has failed
  2. Verify application behavior — Use an HTTP or DNS monitor where appropriate, or an internal probe plus heartbeat
  3. Check the protocol — A successful TCP connection does not verify a UDP service

Need Help?

If you need assistance configuring port monitoring, reach out using the "Need Help?" button on the bottom right corner or email us at support@uptimeobserver.com.