Skip to main content

​
Overview

Port monitoring checks if a specific TCP port is open and accepting connections on your server. This is essential for monitoring services like databases, mail servers, FTP, SSH, and other TCP-based services.
Port monitoring verifies that a service is listening and accepting connections, but doesn’t validate the service is functioning correctly. Use HTTP monitoring for web services to verify full functionality.

​
Use Cases

Database Servers

Monitor MySQL, PostgreSQL, MongoDB, Redis

Mail Servers

Check SMTP, POP3, IMAP availability

File Transfer

Monitor FTP, SFTP, SSH services

Custom Services

Any TCP-based service on custom ports

​
Creating a Port Monitor

1

Basic Configuration

Name: MySQL Database
Target: db.example.com
Port: 3306
Type: Port (TCP)
Check Interval: 60 seconds
Timeout: 10 seconds
2

Select Protocol (Optional)

Choose a protocol for enhanced validation:
  • Generic: Basic TCP connection test
  • SMTP: Mail server protocol validation
  • POP3: Email retrieval validation
  • FTP: File transfer protocol validation
  • SSH: Secure shell protocol validation
  • HTTP/HTTPS: Web server validation (use HTTP monitor instead)
3

Configure Protocol Validation

For supported protocols, enable additional checks like banner validation or test commands.

​
Common Ports

ServicePortProtocol
MySQL3306TCP
PostgreSQL5432TCP
MongoDB27017TCP
Redis6379TCP
SQL Server1433TCP
Oracle1521TCP

​
Protocol Validation

​
Generic TCP

Basic connection test without protocol-specific validation: 
Protocol: Generic
Port: 8080
Connection Timeout: 10s
What it checks:
  • Port is open
  • TCP connection can be established
  • Connection time
Use for: Custom applications, non-standard services

​
SMTP Protocol

Enhanced validation for mail servers: 
Protocol: SMTP
Port: 25
Expect Banner: Yes
Test Command: EHLO uptimeio.com
What it checks:
  • TCP connection established
  • SMTP banner received (e.g., “220 mail.example.com ESMTP”)
  • Optional: Send EHLO command and verify response
Use for: Mail servers, SMTP relays
SMTP validation helps detect when the port is open but the mail service isn’t responding correctly.

​
POP3 Protocol

Validation for email retrieval servers: 
Protocol: POP3
Port: 110
Expect Banner: Yes
What it checks:
  • TCP connection established
  • POP3 banner received (e.g., “+OK POP3 server ready”)
Use for: POP3 email servers

​
FTP Protocol

Validation for file transfer servers: 
Protocol: FTP
Port: 21
Expect Banner: Yes
What it checks:
  • TCP connection established
  • FTP banner received (e.g., “220 FTP Server ready”)
Use for: FTP servers, file hosting services

​
SSH Protocol

Validation for secure shell servers: 
Protocol: SSH
Port: 22
Expect Banner: Yes
What it checks:
  • TCP connection established
  • SSH banner received (e.g., “SSH-2.0-OpenSSH_8.2p1”)
Use for: SSH servers, SFTP services

​
Connection Timeout

Set how long to wait for connection establishment:
TimeoutUse Case
1-5 secondsLocal network, fast services
10 seconds (Default)Standard, works for most scenarios
15-30 secondsSlow networks, distant servers
Start with 10 seconds and adjust based on your service’s typical response time.

​
SSL/TLS Support

For services that support SSL/TLS encryption: 
Port: 993 (IMAP SSL)
SSL Enabled: Yes
Validate Certificate: Yes
What it checks:
  • TCP connection established
  • SSL/TLS handshake successful
  • Certificate validity (if validation enabled)
Enable certificate validation for production services. Disable only for testing with self-signed certificates.

​
Response Data

Port monitors can capture and validate response data:
Validate the server responds with expected text:
Expected Response: "+OK POP3 ready"
Creates incident if response doesn’t match.
Large responses are truncated to prevent excessive data storage:
  • Maximum size: 1 KB
  • Truncation indicator: Response includes truncation notice
Only the first 1 KB of response data is captured. This is sufficient for banner validation.

​
Example Configurations

Name: Production MySQL
Target: db.example.com
Port: 3306
Protocol: Generic
Connection Timeout: 10s
Regions: us-east, us-west

​
Best Practices

Protocol-specific validation provides better detection of service issues:Generic: Only checks if port is open SMTP: Checks if mail service is responding correctlyUse protocol validation for critical services.
  • Fast local services: 5 seconds
  • Standard services: 10 seconds
  • Slow or distant services: 15-30 seconds
Avoid timeouts longer than 30 seconds.
Choose regions based on:
  • Where your users connect from
  • Where your service is hosted
  • Network paths you want to test
For comprehensive monitoring:
  1. Ping: Verify server is online
  2. Port: Verify service is accepting connections
  3. HTTP: Verify service is responding correctly (for web services)

​
Security Considerations

Port monitoring can expose information about your infrastructure. Follow these security practices:
  • Only allow connections from UptimeIO’s IP ranges
  • Use security groups or firewall rules
  • Don’t expose unnecessary ports publicly
  • Never expose database ports publicly if possible
  • Use VPN or private network for monitoring
  • If public, use strong authentication and encryption
  • Monitor from specific IP ranges only
Port monitoring only tests connectivity, not authentication:
  • Service may be running but authentication could be broken
  • Consider application-level monitoring for full validation
  • Use HTTP monitors with authentication for APIs

​
Troubleshooting

Possible causes:
  • Service is not running
  • Wrong port number
  • Firewall blocking connections
  • Service bound to localhost only
Steps to diagnose:
  1. Verify service is running
  2. Check port number is correct
  3. Test connection from your machine: telnet host port
  4. Review firewall rules
  5. Check service bind address
Possible causes:
  • Firewall dropping packets (no response)
  • Network routing issues
  • Service overloaded
  • Timeout set too low
Steps to diagnose:
  1. Increase timeout value
  2. Check firewall logs
  3. Verify network connectivity
  4. Check service load
Possible causes:
  • Wrong service running on port
  • Service misconfigured
  • Service version changed
  • Proxy or load balancer in between
Steps to diagnose:
  1. Review captured banner
  2. Verify correct service is running
  3. Check service configuration
  4. Test direct connection
Possible causes:
  • Certificate expired or invalid
  • Certificate hostname mismatch
  • Unsupported SSL/TLS version
  • Self-signed certificate with validation enabled
Steps to diagnose:
  1. Check certificate expiration
  2. Verify certificate hostname
  3. Test with openssl s_client
  4. Disable validation for self-signed certs (testing only)

​
Port vs HTTP Monitoring

Choose the right monitor type:
FeaturePort MonitorHTTP Monitor
What it checksPort is open, accepting connectionsHTTP service responding correctly
ValidationTCP connection + optional bannerStatus code, headers, body, SSL
SpeedVery fastFast
DetailBasic connectivityFull application validation
Use forNon-HTTP servicesWeb services, APIs
For web services (port 80/443), always use HTTP monitoring instead of port monitoring. HTTP monitors provide much more detailed validation.

​
Monitoring Private Services

To monitor services on private networks:
1

Option 1: VPN

Establish VPN connection between UptimeIO and your private network.
2

Option 2: Bastion Host

Deploy a bastion host that UptimeIO can access, which forwards checks to internal services.
3

Option 3: Monitoring Agent

Deploy a monitoring agent in your private network that performs checks and reports to UptimeIO.
Never expose database or internal service ports directly to the internet without proper security measures.

​
Next Steps

DNS Monitoring

Monitor DNS resolution

HTTP Monitoring

Monitor web services

Notifications

Configure port monitoring alerts

API Reference

Create port monitors via API