Open ports monitoring

Coming soon: Open ports monitoring is currently in development and will be available shortly.

Our open ports monitoring scans all 65,535 TCP ports on your server. You tell us which ports should be open, and we take care of the rest: alerting you when those ports become unreachable, and when any port you didn't list is found open.

Check frequency #

These checks run every 12 hours by default on each of your monitors. A full scan of all 65,535 ports is more intensive than a single-port check, so it runs less frequently. You can customize the frequency in your monitor's settings if you need more or less frequent checks.

How it works #

You define a list of ports that should be open for your server to function properly. For a web server, that's typically port 80 (HTTP) and 443 (HTTPS). For a mail server, you'd add 25, 587, and 993.

We then scan all 65,535 TCP ports and compare the results against your list. This gives you two types of protection:

Availability monitoring #

If any port on your list becomes unreachable across two consecutive scans, we'll alert you. This could mean a crashed service, a firewall misconfiguration, or a network issue.

Common examples of ports you'd want monitored for availability:

• Port 80 (HTTP) - Your web server
• Port 443 (HTTPS) - Your secure web server
• Port 25 (SMTP) - Your mail server

Security monitoring #

If we find any open port that is not on your list, we'll alert you. This is the real security value: you don't need to guess which ports should be closed. Any port that's open and shouldn't be will be flagged automatically.

This catches scenarios like:

• A Redis instance (6379) accidentally exposed without authentication
• A database port (3306, 5432, 27017) opened after a firewall change
• A debug service left running on a random high port after a deployment
• An SSH port (22) on a server that should only serve web traffic

Because we scan all ports, you don't need to maintain a list of "ports that should be closed." If it's not on your "should be open" list and we find it open, you'll know about it.

How we perform port scanning #

We perform a full TCP SYN scan of all 65,535 ports and report back every port that is open. UDP ports are not scanned. The scan runs from our monitoring infrastructure, simulating what an external attacker or legitimate user would experience when trying to connect to your server.

We report the list of open ports we find:

• Open - The port accepted the connection. A service is listening and reachable from the internet.

Any port that is not reported open (because it is closed, firewalled, or unreachable) is treated as not open. We compare the open ports we find against your expected-open list to determine availability and security issues.

Configuring port monitoring #

Port monitoring is available on Server monitors (ICMP ping). It is not available on Website monitors, since those domains often sit behind CDNs or load balancers where port scanning would not reflect your actual server.

To enable port monitoring:

1. Go to your monitor's settings page
2. Find the "Open ports" section
3. Add the TCP ports you expect to be open
4. Save your settings

You can add any port number between 1 and 65,535. Any open port not in this list will trigger a security alert.

Understanding the results #

When we detect an issue, you'll see it in your monitor's dashboard along with details about:

• Which port changed state
• Whether it's an expected port that went down or an unexpected port that appeared
• The current detected state
• When the change was detected

Historical data is kept so you can track when ports change state over time.

Common use cases #

Web server monitoring #

Add ports 80 and 443 to your expected-open list. You'll be alerted if your web server goes down, and if anything else becomes accessible that shouldn't be.

Database security #

You don't need to explicitly list database ports as "should be closed." Simply leave them off your expected-open list. If MySQL (3306), PostgreSQL (5432), or MongoDB (27017) suddenly become accessible from the internet, you'll be alerted automatically.

Service availability #

If you run services on non-standard ports (like an API on port 8080), add those to your expected-open list to monitor their availability.

Security auditing #

The full port scan gives you continuous external verification of your attack surface. Even if you trust your firewall configuration, it's good to verify from an external perspective that only the ports you expect are reachable.

Avoiding false alarms #

Network glitches, brief maintenance windows, or temporary firewall hiccups can cause a single scan to report a port change that resolves itself moments later. To prevent unnecessary alerts, we require two consecutive failed scans before sending a notification.

With the default 12-hour check frequency, this means you'll be alerted within roughly a day of a real issue. This strikes a balance between detection and avoiding noise from transient problems. Increase the check frequency in your monitor's settings if you need faster detection.

Notifications #

You'll receive notifications when:

1. An expected port becomes unreachable - A service you need running has gone down (confirmed by two consecutive scans)
2. An unexpected port is found open - A port that's not on your list is accepting connections (confirmed by two consecutive scans)
3. Issues are resolved - When all ports return to their expected states

Unexpected open port notifications should be treated as high priority. An open port you didn't expect often means a misconfigured firewall, an accidentally exposed service, or something worse.