Port monitoring: watch any port on your server
HTTP Status Code Checker
Free, no sign-up. We only fetch the public URL you enter.
Short answer
Port monitoring checks at a regular interval whether a TCP port on a host – for example 25 for SMTP, 22 for SSH or 3306 for MySQL – accepts connections. If the connection is refused or times out, you get an alert, even when the server still answers a ping. Inverted, the same check warns you when a port that should stay closed, such as a database or remote desktop port, suddenly becomes reachable from the internet. monitordefend does not offer port checks; it monitors websites over HTTP.
- A port monitor opens a TCP connection to host:port and reports whether it succeeds.
- Alert when a port is closed (service down) or when it is open (exposure).
- Use one monitor per host and port; combine with ping and HTTP checks.
A server that answers a ping is not necessarily a server that works. The mail server can stop accepting connections, the database can crash, SSH can hang after an update – while the machine itself stays perfectly reachable. Port monitoring closes that gap: it connects to a specific port on a specific host and checks whether the service behind it still accepts connections. This guide explains what port monitoring is, which ports are worth watching, how to set up a port monitor with standard tools or a monitoring service, how to alert on closed and on unexpectedly open ports, and which mistakes cause false alarms or missed outages.
What is port monitoring?
Port monitoring is the regular, automated check of whether a specific port on a server is open and accepting connections. Every network service listens on a port: a web server on 80 and 443, a mail server on 25, 465 and 587 for SMTP, a database such as MySQL on 3306. A port monitor opens a TCP connection to that host and port at a fixed interval – every minute, every five minutes – and records whether the handshake succeeds, how long it takes and whether the result matches what you expect.
The value lies in what it tests: not the machine, but the service. When a process crashes, runs out of file descriptors or is stopped by a failed update, the operating system usually keeps running and keeps answering network pings. Only a connection attempt on the service’s own port reveals that nobody is listening any more. That is why port monitoring is a standard building block of server monitoring for mail, databases, SSH, FTP, DNS and any custom application that does not speak HTTP.
Why a ping is not enough
A ping uses ICMP, a protocol handled by the operating system’s network stack. It tells you that the machine is powered on and routable – nothing more. A server can answer pings for days while the mail daemon has crashed, the database refuses connections because it hit its connection limit, or a firewall change blocks the port your users need.
- Ping (ICMP) The machine is reachable
- Port (TCP) A service accepts connections
- Protocol check The service answers correctly
- Real use Mail is delivered, queries return
Port monitoring sits one layer above. A successful TCP handshake proves that a process is bound to the port and that the network path, including firewalls and load balancers, lets the connection through. For even more certainty, some monitors go one step further and speak the protocol – reading the SMTP greeting, sending a database ping, requesting an HTTP page. Each layer catches a class of failure the layer below cannot see, which is why many teams run ping and port monitors side by side on the same host.
Which ports should you monitor?
Monitor every port that your users, applications or colleagues depend on and that could fail independently of the others. The table lists the ports most teams start with. If your service uses a non-standard port – an application server on 8080, a message broker on 5672, a game server on a custom port – you can monitor it exactly the same way; port monitoring works for any TCP port.
Two rules help with the selection. First, monitor from the perspective of the people who use the service: if customers send mail through port 587, that port matters more than port 25 on an internal relay. Second, add the ports that should never be reachable to a separate list. They need the inverted check described further below.
| Port | Service | Typical expectation |
|---|---|---|
| 80 / 443 | HTTP / HTTPS web server | Open |
| 22 | SSH remote administration | Open (often only for some networks) |
| 21 | FTP file transfer | Open if used, otherwise closed |
| 25 / 465 / 587 | SMTP mail transfer and submission | Open on mail servers |
| 143 / 993 | IMAP / IMAPS mailbox access | Open on mail servers |
| 110 / 995 | POP3 / POP3S mailbox access | Open if offered |
| 53 | DNS (TCP for large answers and zone transfers) | Open on name servers |
| 3306 | MySQL / MariaDB | Closed to the internet |
| 5432 | PostgreSQL | Closed to the internet |
| 3389 | Remote Desktop (RDP) | Closed to the internet |
Monitoring email ports: SMTP, IMAP and POP3
Email is the classic case for port monitoring, because mail problems stay invisible for a long time. A website outage is noticed within minutes; a mail server that stops accepting connections is usually noticed hours later, when someone asks why the invoice never arrived. By then, sending servers have queued or bounced messages and customers have drawn their own conclusions.
$ nc -zv mail.example.com 25 Connection to mail.example.com 25 port [tcp/smtp] succeeded! $ openssl s_client -connect mail.example.com:993 -quiet * OK [CAPABILITY IMAP4rev1 ...] Dovecot ready. $ nc -zv mail.example.com 110 nc: connect to mail.example.com port 110 (tcp) failed: Connection refused
A complete mail setup has several ports that can fail separately. SMTP on port 25 receives mail from other servers, port 587 (submission, with STARTTLS) and port 465 (implicit TLS) accept mail from your own users and applications. IMAP on 143 and 993 and POP3 on 110 and 995 let mail clients fetch messages. A crashed Dovecot process takes down IMAP and POP3 while SMTP keeps running; a broken Postfix configuration does the opposite. One port monitor per port tells you immediately which part is affected.
For mail, a TCP connect is a good start, but a protocol-aware check is better: a healthy SMTP server greets with a 220 line, an IMAP server with “* OK”. A monitor that waits for that banner also catches a service that accepts connections but hangs before answering.
Port monitoring for your DNS server
If you run your own name servers, port 53 deserves a monitor of its own. DNS mostly uses UDP, but TCP on port 53 is required for answers larger than a single UDP packet – common with DNSSEC – and for zone transfers between primary and secondary servers. A name server that accepts UDP but not TCP queries can produce strange, intermittent resolution failures that are hard to trace.
A TCP port check on 53 confirms that the DNS service is up and reachable through your firewall. It does not confirm that the answers are correct; for that, a DNS monitor that queries a record and compares the result is the right tool. Combining both gives you availability and correctness of the DNS connection your whole infrastructure relies on.
Databases, SSH, FTP and custom services
Databases are the second big group. When an application reports “connection failed”, the first question is whether the database listens at all. A port monitor on 3306 for MySQL or 5432 for PostgreSQL answers it instantly – but run it from inside your network or from an allow-listed monitoring address, because a database port should not be open to the whole internet. The same applies to caches such as Redis on 6379 and to message brokers.
SSH on port 22 is your way in when everything else fails, so it is worth knowing early when it stops answering, for example after a configuration change or because a brute-force protection tool has locked out the monitoring address. FTP on port 21 still matters for many hosting setups and file exchange with partners. And any in-house service – an API gateway on 8443, a licence server, a VPN endpoint – can be watched with the same simple connect test.
Alert when a port is closed – or when it is open
Most port monitors offer two alert conditions. “Alert when port is closed” is the usual choice: the monitor is up as long as the connection succeeds and goes down when it is refused or times out. Use it for every service that must stay available – mail, web, SSH, DNS.
- Port 3306 closed – monitor reports “as expected”
- Firewall rule changed during a deployment
- Port 3306 accepts connections from the internet – alert
- Rule reverted, port closed again – resolved
“Alert when port is open” inverts the logic. The monitor is up while the port is closed or unreachable and goes down as soon as it accepts a connection. This is a security check: a database port, a remote desktop port such as 3389 or an admin interface that becomes reachable from the internet after a firewall change, a new container or a misconfigured cloud security group is an open door. Hearing about it within minutes instead of in the next security audit can make the difference.
Keep in mind that an inverted monitor treats an unreachable server as healthy. If the whole host goes offline, the port is “closed” and the monitor stays green. Pair it with a ping monitor or a normal port monitor on another port of the same host so that a full outage is still reported.
What a port monitor measures
The core metric is the port status: open or closed, and whether that matches the expected state. From the series of checks a monitor derives availability – the share of successful checks as an uptime percentage – and an incident history with the start, end and duration of every outage.
Most tools also record the response time, here the time needed to complete the TCP connection. Connect times are usually short and stable, so a sudden rise is a useful early warning: an overloaded server, a saturated network link or a service whose accept queue is full often slows down before it stops answering entirely. Some services let you set a threshold and alert on slow connections, not only on failed ones.
- Port status – open or closed, compared with the expected state
- Connect time – how long the TCP handshake takes
- Availability – uptime percentage per day, month and year
- Incident history – when each outage started, ended and how long it lasted
How to set up port monitoring
In a hosted monitoring service, creating a port monitor usually takes three steps. First, choose the port monitoring type and enter the hostname or IP address and the port – for example mail.example.com and 587. Second, choose the alert condition (closed or open), give the monitor a clear name, add it to a group or tag and select who gets notified. Third, set the interval, the timeout and, where offered, the locations to check from. Save it, and the first check runs within seconds.
# /etc/cron.d/portcheck – every 5 minutes */5 * * * * root nc -z -w 5 db.example.com 5432 \ || echo "PostgreSQL port closed" | mail -s "Port alert" ops@example.com
Without a service, you can build a simple check yourself with a cron job and netcat, as shown below. It works, but it has two weaknesses: it runs on your own network, so it cannot see problems on the path from the internet, and if the machine running the script fails, the monitoring fails silently with it. An external monitor avoids both, which is why self-built scripts are usually a supplement rather than the main safety net.
- Enter host or IP and port; one monitor per host-and-port combination
- Choose “alert when closed” for services, “alert when open” for ports that must stay shut
- Pick interval and timeout, add notification recipients
- Name monitors after the service, not the number: “SMTP submission” beats “port 587”
Checking a port manually
When an alert arrives, a manual test confirms it and narrows the cause. From a machine outside your network, “nc -zv host port” reports whether the connection succeeds, is refused or times out. A refusal means the host is reachable but nothing listens on the port – the service is down or bound to a different address. A timeout usually means a firewall drops the packets or the host itself is unreachable.
On the server itself, “ss -tlnp” (or “netstat -tlnp” on older systems) lists the ports that are actually listening and the processes behind them. If the port is listed locally but unreachable from outside, look at the firewall, the security group or the load balancer. For TLS ports, “openssl s_client -connect host:port” additionally shows whether the certificate and handshake work. On Windows, “Test-NetConnection host -Port 443” in PowerShell does the same as netcat.
Intervals, timeouts and multi-location checks
The check interval decides how quickly you learn about a failure. One to five minutes is common for production services; critical ones may justify 30 seconds, while internal tools are fine at ten minutes. Shorter intervals find outages faster but also find more short blips, so they go hand in hand with confirmation logic.
Set the timeout with care. Too short, and normal network jitter produces false alarms; too long, and a hanging service takes minutes to be reported. Five to ten seconds is a sensible default for a TCP connect. Good monitors also confirm a failure before alerting – with a second attempt or from a second location. Multi-location checks, where several probes in different regions test the same port, separate a real outage from a regional network problem and catch issues that only affect some parts of the internet.
Notifications, recurring alerts and maintenance windows
An alert is only useful if it reaches someone who can act. Depending on the service, notifications go out by email, SMS, voice call, push or into chat and incident tools such as Slack, Microsoft Teams or PagerDuty. Choose channels by urgency: a closed mail port at night may justify a phone call, a slow FTP server an email.
Two features keep alerting manageable. Recurring notifications repeat the alert while an outage lasts, so a message that arrived at 3 a.m. and was overlooked is not the only one. Maintenance windows pause monitoring during planned work – a database upgrade, a mail server migration – so that expected downtime neither triggers alerts nor spoils the availability statistics. Team access with read, write or notify-only roles lets several people see the monitors without everyone being able to change them.
Port monitoring compared with ping and HTTP monitoring
The three check types complement each other rather than compete. Ping is the cheapest and broadest signal, port checks confirm individual services, and HTTP checks verify that a website or API returns the right response. For a web server, an HTTP monitor is usually the better choice than a bare port check on 443, because it also catches error pages and expired certificates. For everything that does not speak HTTP, the port monitor is the main tool.
| Check | Tests | Misses |
|---|---|---|
| Ping (ICMP) | Host is reachable on the network | Crashed services, blocked ports, ICMP filtered by firewalls |
| Port (TCP) | A service accepts connections on host:port | Wrong answers from a service that is listening |
| HTTP(S) | Status code, content, redirects, response time | Non-HTTP services such as mail or databases |
Choosing a port monitoring tool
Port monitoring tools fall into three groups. Hosted uptime services check from the internet, need no installation and are quick to set up; many offer a free tier with a handful of monitors and longer intervals, while paid plans add shorter intervals, more locations and more notification channels. Self-hosted network monitoring systems such as Nagios, Zabbix or Prometheus with a blackbox exporter can check thousands of internal ports, but you operate and monitor them yourself. Simple scripts are fine for a single server but rarely scale.
When comparing, look at the minimum interval, the number of check locations, whether failures are confirmed before alerting, which notification channels are included, whether the inverted “alert when open” condition exists, and how long the history is kept. The cheapest option that misses an outage is the most expensive one.
Common port monitoring mistakes
The most frequent mistake is monitoring the wrong thing: a port check on 443 for a website that shows an error page, or on port 25 of an internal relay when users submit mail through 587. The second is blocking your own monitor – rate limiters, fail2ban or a cloud firewall that bans the probe’s IP turn a healthy service into a permanent alarm. Allow-list the monitoring addresses where you can.
Other classics: one monitor for several services, so the alert does not say what broke; no inverted checks for database and remote desktop ports; alerts sent to a mailbox nobody reads; and no second check before alerting, which floods the team with false alarms until everyone ignores them.
Where monitordefend fits
monitordefend does not monitor TCP ports, mail servers or databases; it watches websites. Its uptime check requests your homepage over HTTP every five minutes and confirms an outage with a second attempt, and it tracks response time, broken links, checkout pages and suspicious changes. Alerts are sent by email. For mail, SSH or database ports, use a dedicated port monitor alongside it.
Frequently asked questions
What is port monitoring?
Port monitoring regularly checks whether a TCP port on a server is open and accepting connections. It shows whether the service behind the port – mail, database, SSH – is reachable, not just the machine. Inverted, it alerts when a port that should stay closed becomes open.
Which ports can I monitor?
Any TCP port: 80 and 443 for web servers, 22 for SSH, 21 for FTP, 25, 465 and 587 for SMTP, 143 and 993 for IMAP, 110 and 995 for POP3, 53 for DNS, 3306 for MySQL, 5432 for PostgreSQL and any custom port your application uses.
What is the difference between port monitoring and ping monitoring?
Ping checks whether the host answers ICMP requests; port monitoring checks whether a specific service accepts TCP connections. A server can answer pings while its mail or database service is down, so many teams use both.
Can I monitor email services with port monitoring?
Yes. Monitor SMTP on 25, 465 and 587, IMAP on 143 and 993 and POP3 on 110 and 995 separately. Each service can fail on its own, and mail problems are usually noticed much later than website outages.
How do I set up port monitoring?
Enter the hostname or IP and the port, choose whether to alert when the port is closed or open, set the interval and timeout and add notification recipients. For a quick self-built check, a cron job with “nc -z” works on a single server.
Is port monitoring free?
Many hosted uptime services include port monitors in a free tier with longer intervals and email alerts; paid plans add shorter intervals, more locations and channels such as SMS or chat. Open-source tools are free but need your own server.
Can I monitor multiple ports on the same server?
Yes, with one monitor per host and port, for example 443, 22 and 3306 on the same machine. Separate monitors make it obvious which service is affected when an alert arrives.
Can I get alerted when a port is open?
Yes, with the inverted condition “alert when port is open”. Use it for database, remote desktop and admin ports that should never be reachable from the internet, and pair it with a normal check so that a full server outage is still reported.
Does monitordefend offer port monitoring?
No. monitordefend monitors websites over HTTP – uptime, response time, links, indexing, checkout and integrity – and sends email alerts. Use a dedicated tool for TCP ports.
Related pages
Keep your websites under watch
Start for free and set up your first check in minutes.
Start for free