Find the ports you never meant to open.
One config change can leave a database listening on the public internet. UptimeStatus scans your hosts and flags anything that should not be there.
Nobody opens a port on purpose at 6pm on a Friday.
Exposed ports rarely come from bad decisions. They come from a Docker port mapping that bound to 0.0.0.0, a security group edit that was supposed to be temporary, a new service that shipped with its admin port on defaults. Nothing breaks, so nothing tells you.
A port scan monitor sweeps the host on a schedule and compares what it finds against what you said should be there. The gap between those two lists is exactly the report you want, before someone else runs the same scan.
Both failure directions, both alerted.
Declare the ports that should be open, say 22 and 443, and every scan is judged against that baseline. When an expected port is no longer open, that is an availability problem: an incident opens as investigating, naming the missing ports.
When a port outside the baseline shows up open, that is an exposure problem: a separate incident opens as monitoring, naming the unexpected ports, so you can close it, or promote it to expected if it turns out to be legitimate.
What port scan monitoring includes.
- Well-known ports by default every scan sweeps ports 1 through 1024, plus any ports you declare as expected, so the usual suspects are always covered.
- Full-range scans, opt-in turn on full scanning to sweep all 65535 ports when you want the complete picture. A full sweep takes a few minutes.
- An expected-ports baseline declare which ports should be open. Everything else on that host becomes a finding instead of background noise.
- Incidents for both directions an expected port that closes and an unexpected port that opens each get their own incident, with the ports named.
- Every scan stored each run records the full list of open ports next to your expected list, so you can diff any two scans after the fact.
- 10 notification channels email, SMS, Slack, Discord, Microsoft Teams, PagerDuty, Opsgenie, Pushover, ntfy, and webhooks.
The baseline is three lines of config.
A scan monitor is a host plus a list of expected ports. Set fullScan when you want the entire 65535-port range instead of the well-known default. Create it in the dashboard, or from your provisioning scripts so every new host ships with its own scanner.
The same API powers the dashboard, so anything you can click, you can automate.
curl -X POST https://uptime-status.org/api/monitors \ -H 'Content-Type: application/json' \ -d '{ "name": "db-1 exposure scan", "url": "db-1.yourcompany.com", "type": "port_scan", "config": "{\"expectedPorts\": [22, 443]}" }'
Port scan monitoring, answered.
What does a port scan monitor actually check?
It attempts a TCP connection to every port in the scan range on your host and records which ones accept. By default that range is the well-known ports, 1 through 1024, plus any ports you list as expected. Full-range scans of all 65535 ports are available as an opt-in setting per monitor.
What counts as a finding?
Two things. An expected port that is no longer open, which usually means a service died or a firewall rule went too far, opens an incident marked investigating. And once you have declared expected ports, any other open port on the host opens an incident marked monitoring, because it may be intentional but you should be the one deciding that.
Will this catch a deploy that exposed my database?
That is the core case it was built for. If 5432 is not in your expected list and a config change leaves Postgres listening on a public interface, the next scan reports 5432 as unexpectedly open and an incident opens with that port named in the cause.
How often do scans run?
Port scans are heavier than a single uptime check, so they run as scheduled scans rather than every 30 seconds. A default scan covers over a thousand ports, and a full-range scan can take a few minutes on a well-firewalled host, since every filtered port has to time out.
Is it safe to scan my own hosts?
Scanning infrastructure you own or operate is standard security hygiene, and the scan is plain TCP connection attempts, nothing exploit-shaped. Only point it at hosts you are authorized to scan. Some providers ask you to notify them about scheduled scanning, so check your host's policy.
Pairs well with.
TCP port monitoring
A scan finds surprises across the whole host. A port check watches one critical port every few seconds.
Learn moreSSL monitoring
Open ports are one class of quiet security regression. Expiring and misconfigured certificates are another.
Learn moreIncident management
Scan findings open incidents with a timeline, so an exposed port gets an owner instead of a shrug.
Learn moreStart monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.