Port Monitoring Explained: Why You Should Monitor More Than Just HTTP

Your website loads perfectly. Your HTTP monitor shows green. But behind the scenes, your Redis cache is unreachable on port 6379, causing every page to make direct database queries. Response times have tripled. Your MySQL replica stopped accepting connections on port 3306 an hour ago. Your SSH daemon crashed, so your team cannot access the server to investigate. HTTP monitoring sees none of this. Port monitoring sees all of it.

What Is Port Monitoring?

Port monitoring checks whether a specific TCP port on a server is open and accepting connections. It initiates a TCP handshake (SYN, SYN-ACK, ACK) to the target IP and port. If the handshake completes, the service is accepting connections. If it is refused or times out, the service is down.

Unlike HTTP monitoring which requires a web server to interpret the request, port monitoring operates at the transport layer. It does not care what protocol the service speaks — it only verifies that the service is listening.

Critical Ports Every Team Should Monitor

Databases:

• MySQL/MariaDB — port 3306
• PostgreSQL — port 5432
• MongoDB — port 27017

Caches and queues:

• Redis — port 6379 — Redis crashing due to maxmemory limits is one of the most common infrastructure issues.
• Memcached — port 11211
• RabbitMQ — port 5672

Mail servers:

• SMTP — port 25 or 587
• IMAP — port 993
• POP3 — port 995

Infrastructure:

• SSH — port 22 — if SSH is down, your team cannot access the server to fix anything.
• DNS — port 53
• Elasticsearch — port 9200

When Port Monitoring Catches What HTTP Does Not

Scenario 1: Redis goes down. Your application uses Redis for caching. When Redis crashes, every page hits the database directly. Response times triple. Your HTTP monitor still shows 200 OK — below the threshold. A port monitor on 6379 catches this immediately.

Scenario 2: Database replica fails. The replica crashes, your connection pooler fails over to the primary, the primary becomes overloaded. Your HTTP monitor finally alerts when the site throws 503 errors — 20 minutes after the original problem. A port monitor on the replica's 3306 would have alerted within 1 minute.

Scenario 3: SSH becomes inaccessible. A firewall rule update accidentally blocks port 22. The website is unaffected. But when an unrelated issue occurs later, your engineer cannot SSH in to investigate. A port monitor on 22 would have flagged the issue hours earlier.

Setting Up Port Monitors in Monitorion

1. Create a new monitor and select Port.
2. Enter the hostname or IP address of the server.
3. Enter the port number — 3306, 6379, 22, etc.
4. Set the timeout — 5 seconds is a reasonable default.
5. Configure your check interval and alert channels.

For internal services, use Monitorion's private workers to monitor ports on servers with no public IP address.

A Recommended Port Monitoring Setup

• Database primary — port 3306/5432
• Database replica(s) — port 3306/5432
• Redis/Memcached — port 6379/11211
• SSH — port 22 (on every server you manage)
• Message queue — port 5672

HTTP monitoring tells you the front door is open. Port monitoring tells you the entire building is operational. Use both. Start monitoring for free and add port checks to your critical infrastructure today.