Definition
Port monitoring checks whether a particular TCP port on a host is open and accepting connections — for example, port 443 for HTTPS, 25 for SMTP, or 5432 for PostgreSQL. It confirms that a service is listening on the expected port.
It's more informative than a ping (which only tests the host) but less informative than an application check (which tests the actual response). A port can be open while the service behind it is malfunctioning.
Why It Matters
Port monitoring is useful for non-HTTP services — mail servers, databases, custom TCP services — where you want to know the service is at least accepting connections. For web services, though, an HTTP check is usually the better choice because it validates the actual response.
How It Works
The monitor attempts to open a TCP connection to a host and port. If the connection succeeds, the port is open and the service is listening; if it's refused or times out, the port is considered down. Some checks also send a protocol-specific probe to verify the service responds correctly.
Real-World Example
A team monitors port 5432 on their database host. When the database process crashes, the port stops accepting connections and the port check fails — alerting the team even though the host itself is still online and answering pings.
Best Practices
- Use port monitoring for non-HTTP services like mail or databases
- Prefer HTTP checks for anything served over the web
- Remember an open port doesn't guarantee the service works correctly
- Combine port checks with application-level probes where possible
- Restrict exposed ports for security, monitoring only what should be reachable
Common Mistakes
- Using port checks for web services where HTTP is more meaningful
- Assuming an open port means the service is fully healthy
- Monitoring ports that shouldn't be publicly exposed
- Ignoring protocol-level failures behind an open port
- Confusing port reachability with application correctness
In Monitoristic
Monitoristic monitors HTTP/HTTPS endpoints rather than arbitrary TCP ports. For web apps and APIs this is what you want; for a non-HTTP service, the common pattern is to expose a small HTTP health endpoint and monitor that.