Skip to content

Port Monitoring

Monitor the availability of TCP and UDP services by checking if specific ports are open and responding on your servers.

Overview

Port monitoring verifies that a specific network port is open and accepting connections. This is ideal for monitoring services that don't use HTTP, such as:

  • Database servers (MySQL, PostgreSQL, MongoDB)
  • Mail servers (SMTP, IMAP, POP3)
  • Game servers
  • SSH access
  • Custom TCP/UDP services

UptimeObserver attempts to establish a connection to the specified port and reports success or failure based on whether the connection is accepted.

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.168.1.100 — Using an IPv4 address
  • 2001:db8::1 — Using an IPv6 address

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

Select the network protocol:

Protocol Description Use Case
TCP Transmission Control Protocol Most services (databases, mail, SSH)
UDP User Datagram Protocol DNS, game servers, streaming

TCP vs UDP

TCP provides connection-oriented monitoring with reliable detection. UDP is connectionless, so monitoring confirms the port is listening but may not verify the service is fully functional.

Timeout

Set the maximum time to wait for a connection (in seconds):

  • Default: 10 seconds
  • Recommended: 5-15 seconds for most services
  • Slow services: Up to 30 seconds if needed

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:

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

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

Port monitoring is ideal for services that:

  • Aren't exposed via HTTP
  • Run on non-standard ports
  • Need simple up/down availability checks

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. Use a VPN or private network
  2. Restrict access by IP address
  3. Consider monitoring from within your network instead

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 — Ensure you're using the correct protocol (TCP/UDP)

UDP Monitoring Shows False Positives

UDP is connectionless, which can make monitoring less reliable:

  1. Use TCP if available — Many services support both protocols
  2. Verify with application-level checks — Consider additional HTTP monitoring if the service has a web interface
  3. Accept limitations — UDP monitoring confirms the port is listening but may not detect all failures

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.