Port monitoring
Upcheck's port check opens a TCP connection to the ports you name every five minutes — SSH, a database, mail, a game server — and tells your team the moment one stops accepting connections, by email, Slack, Discord, Teams, or webhook.
$10/month base · $1 per website · port check included
The website answers on 443. Everything it needs listens somewhere else.
A database that stops listening, a mail server that stops accepting connections, a jump host whose SSH daemon didn't come back after a reboot — none of these returns a 500. The website may keep serving cached pages for an hour while the checkout behind it quietly fails, and the first person to notice is the one who needed the shell during the incident and couldn't get it.
TCP port monitoring is the plain answer: connect to the port every few minutes, the way a client would, and alert when the connection stops being accepted. Because it stops at the handshake, one check covers PostgreSQL, IMAP, SSH, RDP, a game server and a gRPC endpoint alike — anything that listens on a socket, whether or not it speaks HTTP. Upcheck's port check does exactly that, on the website's own hostname or on the origin server behind it.
The same detection math as the uptime check: a failure is confirmed twice, so one dropped packet on a busy link never pages anyone.
TCP port monitoring in three steps
- 01
Name the host and the ports
Up to ten TCP ports per website — 22 for SSH, 5432 for PostgreSQL, 993 for IMAP, 25565 for a Minecraft server, anything from 1 to 65535. By default the check connects to the website's own hostname; name a different host, such as the origin server behind a proxy or a plain IP address, when the ports live somewhere else.
- 02
Every 5 minutes, a connect and a close
The host is resolved once, then each port gets a TCP connection attempt from Cloudflare's network with a four-second timeout. The moment the handshake completes the connection is closed again. Nothing is sent: no banner is read, no protocol is spoken, so the check works the same for a database, a mail server and a game server.
- 03
A failure is confirmed, then your rules fire
A refused connection, a timeout, or a host that no longer resolves fails the probe. One failing probe starts the clock; the second, five minutes later, confirms it and fires the port rules — email, Slack, Discord, Microsoft Teams, or a webhook — naming which ports failed and why. A recovery alert follows when every port answers again.
Closed and filtered are different problems
A port that refuses a connection at once has a host that is up and a service that is not. A port that lets the connection time out has a firewall dropping packets, a host that is gone, or a route that broke. The alert says which, per port, so the first minute of the incident goes to the right place.
Every probe also keeps the address the host resolved to. A database host whose DNS was repointed shows up here as a changed address on the same open port — the kind of change that is otherwise invisible until something else breaks.
Every state a port check can be in
- Open
Every watched port accepted a connection on the last probe. Nothing to report, and no alert fires.
- Failing
At least one port refused the connection or let it time out, or the host stopped resolving. One failing probe starts the clock; a second, five minutes later, confirms it and fires your rules.
- Unprobeable
The host resolves to Cloudflare's edge, which exposes no raw TCP ports. The check says so instead of reporting every port closed; name the origin server as the host to probe it.
- Not set up
Every website has a port check waiting, created disabled. Until you name the ports, it costs nothing and connects to nothing.
One alert when a port stops answering, one when it comes back
A port rule fires once a failure is confirmed by the second probe, naming the host, each port that failed and why — refused, or no response within four seconds — and how long it has been failing. A recovery alert follows once every watched port accepts a connection again.
The first port check an organization sets up creates its own email alert rule automatically, so it alerts with no further setup. From there it behaves like every other rule — scope it to specific websites, and route it to email, Slack, Discord, Microsoft Teams, or a webhook, where it arrives as a structured port.alert event carrying port_down or recovered, so your own tooling can route a closed database port apart from a slow website.
What makes a port monitoring tool worth the alerts it sends
The check is only as useful as the host and ports you give it. These are the rules that stop it alerting when nothing is wrong, and make sure it does when something is.
- 01
Name the origin, not the proxy
A website served through Cloudflare resolves to Cloudflare's edge, and the edge exposes no raw TCP ports. Point the port check at the origin server's hostname or IP — the machine actually listening on 22 or 5432 — rather than the website's public name.
- 02
Watch the ports the site depends on, not the site
The uptime check already proves 443 answers. A port check earns its place on the services behind it: the database, the cache, the mail server, the SSH jump host, the queue broker that the web tier quietly needs.
- 03
Port 25 is off the table
Cloudflare doesn't allow outbound connections to port 25, so an SMTP listener can't be probed from here. Watch the submission port, 587, or the TLS port, 465, instead — those are the ones your own mail clients use anyway.
- 04
Up to ten ports, one host, one check per website
A port check names one host and up to ten ports. Ports on two different hosts want two websites, each with its own port check, each alerting on its own.
- 05
Expect filtered, not closed, from a firewall
A firewall that drops packets produces a four-second timeout, which the probe reports as filtered. A service that is down but whose host is up produces an immediate refusal, reported as closed. The distinction tells you where to look.
- 06
Pause it during maintenance
A port check can be paused without forgetting its settings, so a planned database restart doesn't page the on-call rota. Switch it back on when the window closes.
What people point a port check at
SSH on a bastion or jump host
The first thing anyone needs during an incident is a shell. A port check on 22 tells you the door is open before you need to walk through it.
Mail servers
IMAP on 993, POP3 on 995, submission on 587 or 465. A mail server that stops accepting connections loses mail silently; a port check makes it loud.
Databases and caches on a private host
PostgreSQL on 5432, MySQL on 3306, Redis on 6379, MongoDB on 27017 — on a host that exposes them to the application tier. When the listener disappears, the web app's errors are the second alert; this is the first.
Game servers
A Minecraft server on 25565, a custom game on whatever port it binds. Players notice within seconds; a port check tells you before the Discord does.
VPN, SFTP and RDP endpoints
OpenVPN over TCP on 1194, SFTP on 22 or a custom port, a Windows host on 3389. Remote access that fails is usually discovered by the person who needed it most.
Non-HTTP APIs and brokers
gRPC on 50051, MQTT on 1883, AMQP on 5672, a load balancer's TCP health endpoint. Anything that speaks over a socket but not over HTTP gets the same connect-and-close probe.
An HTTP API wants more than an open port — a status code, a body, a response time. That is the uptime check's HTTP options, not the port check.
What this port monitoring is not
Not a port scanner
It connects to the ports you name and alerts when one stops answering. It never sweeps a range, and it can't alert when a port that should be closed opens — that is a security scanner's job, not a monitor's.
Not a service check
A completed TCP handshake is the whole test. Nothing is sent, no banner is read, no TLS is negotiated, no query runs. A database that accepts connections and then refuses every login looks open here.
Not UDP, not ICMP
TCP only. A DNS server on UDP 53, a game server on UDP, or a plain ping have no connection to complete, so there is nothing for this check to confirm.
Not multi-location
Every connect comes from Cloudflare's network, from one place. A firewall that allows Cloudflare's ranges but blocks the wider internet will look open; one that blocks Cloudflare will look filtered.
Included in the dollar
$10 per month for the workspace, plus $1 per website per month — and the dollar covers everything Upcheck watches on that website: uptime every 5 minutes, up to ten ports every 5 minutes once you set the port check up, the keyword and page change checks every 5 minutes once you set them up, the SSL certificate every 12 hours, DNS every 6, and the domain registration daily. There is no per-port price, no tier that withholds it, and no cap on how many of your websites run one. A workspace can track up to 500 websites.
Comparing monitoring tools? The honest Oh Dear alternative page lays out what is included on Upcheck's one plan, and what is not.
Frequently asked questions
What is port monitoring?
Port monitoring is a check that repeatedly opens a TCP connection to a specific port on a host — 22 for SSH, 5432 for PostgreSQL, 993 for IMAP — and alerts when the connection stops being accepted. It answers a narrower question than uptime monitoring: not whether a website returns a page, but whether a particular service is still listening at all. Because it stops at the TCP handshake, it works the same for any service, whatever protocol it speaks.
How is port monitoring different from uptime monitoring?
An uptime check makes an HTTP request and judges the response: the status code, how long it took, optionally the body. A port check makes a TCP connection and judges only whether it was accepted. Uptime monitoring is for websites and APIs; port monitoring is for the services behind them, and for anything that doesn't speak HTTP. Upcheck runs both, five minutes apart, from the same dashboard.
Can it monitor a server behind Cloudflare?
Not through the proxied hostname. A site served through Cloudflare resolves to Cloudflare's edge, which exposes no raw TCP ports, so every connect there would fail whatever the origin is doing. Upcheck reports that host as unprobeable instead of closed. Name the origin server's own hostname or IP as the port check's host and the probe reaches the machine that is actually listening.
Which ports can it monitor?
Any TCP port from 1 to 65535, up to ten per website, except 25: Cloudflare doesn't allow outbound connections to SMTP, so a port 25 listener can't be probed from Cloudflare's network. Watch 587 or 465 for mail instead. The host can be the website's own hostname, any other hostname, or an IPv4 or IPv6 address.
Does it monitor UDP ports?
No. UDP has no handshake, so there is no connection to accept or refuse and nothing for the probe to confirm without speaking the service's own protocol. A DNS resolver on UDP 53 or a game server on UDP is outside what this check can see; TCP listeners on the same host are not.
Does it check that the service works, or only that the port is open?
Only that the port accepts a TCP connection. Nothing is sent after the handshake — no banner is read, no TLS is negotiated, no query or login is attempted — which is what lets one check cover a database, a mail server and a game server alike. A service that accepts connections and then misbehaves needs a protocol-aware check; for an HTTP service, that is what the uptime check's HTTP options are for.
Can it alert when a port opens that should be closed?
No. The check alerts when a port you named stops accepting connections; it has no notion of a port that should be refusing them, and it never scans ports you didn't name. Finding unexpected open ports is a security scanner's job. The free port checker on this site will show you what a host exposes right now, by hand.
How often does it check, and how quickly does it alert?
Every 5 minutes, the same cadence as the uptime check, with a four-second connect timeout per port. A failure is confirmed by a second probe before any rule fires, so a single dropped packet never pages anyone; a real outage alerts within ten minutes of starting, and a recovery alert follows once every port answers again.
Know when the service behind the site stops listening.
Add the websites you own, name the ports they depend on, and let the probes keep knocking for you.