Port Monitoring

The ports that should answer, do — and nothing surprising is open to the world.

Two Questions, Not One

Here's the thing almost nobody tells you when you first put a server online. “Is my service listening?” and “can the world actually reach it?” are two different questions, and the answer to one tells you almost nothing about the other. Your web server can be happily bound and listening on port 443 while every visitor gets a connection timeout — because a firewall rule, a security group, or a misconfigured router is quietly sitting between “listening on the box” and “reachable from the internet.”

Port monitoring answers the second question, and only the second question. From the outside — the way an actual customer's browser sees you — CleverUptime opens a real TCP connection to the ports that matter and checks that something on the other end says hello. That's the whole trick, and it's a surprisingly honest one: nothing simulates “the rest of the world can reach you” better than actually being the rest of the world.

The Inside View and the Outside View

From inside the box, you already have the tools to see what's listening. ss -tlnp (or the older netstat -tlnp) prints every socket in the LISTEN state — which process owns it, which address it's bound to, which port it's parked on. If you want to know which program grabbed a given port, lsof -i :443 answers it in one line. That's the inside view: what your server thinks it's offering.

The outside view is the reality check. A service bound to 127.0.0.1 is listening — ss will happily confirm it — but it's listening only to itself, and no port probe from the internet will ever reach it. A service bound to 0.0.0.0 is listening to everyone, firewall permitting. Port monitoring is how you reconcile the two: it confirms from the internet what ss shows you locally, and it catches the gap when those two stories disagree.

Listening is not the same as reachable

A firewall sits between “the kernel is listening on this port” and “a stranger on the internet can connect to it.” That gap is where most “but it works on my machine” outages live — the service is up, the port just never made it past the wall.

The Open Port You Didn’t Mean to Open

Now the part that turns port monitoring from a uptime check into a security check. An open port that should be open is fine. An open port that shouldn't be is a story — and it's the single most common first-timer mistake there is. You spin up a database, it binds to 0.0.0.0 by default, there's no firewall in front of it, and now MySQL on 3306 or PostgreSQL on 5432 is answering connections from anyone on the planet who cares to look. And people do look; the internet's background noise is mostly automated scans hunting for exactly this.

When CleverUptime probes your server from the outside and finds a database port answering the open internet, that isn't a green light — it's a flare. We flag it, tell you which service is exposed, and point you at the fix: bind it to 127.0.0.1 or put a firewall in front of it. The best alert is the one about the door you forgot you left open.

A database on the open internet is the classic mistake

If 3306 (MySQL) or 5432 (PostgreSQL) answers from outside your network, assume it's being scanned right now. Bind the service to 127.0.0.1, or firewall the port — an open database port is not a monitoring footnote, it's the headline.

It Knows Which Ports to Watch

Here's the part people don't expect. You don't tell CleverUptime which ports to monitor. The moment the agent runs, it sees which services are actually running on the box — the web server, the database, the mail daemon, the SSH on 22 — and from that it knows exactly which ports should be answering. So it provisions the right external probes automatically, with sensible settings, and starts watching them. No forms, no “add your first port check” wizard, no guessing port numbers from memory.

That inside-knowledge is what makes the outside check smart. A blind port scanner can only tell you a port is open; it has no idea whether that's expected. CleverUptime knows what the box is for, so it can tell the difference between “443 is open, good, that's your website” and “5432 is open, and nothing on this server should be exposing PostgreSQL.” Same observation, completely different verdict — and the verdict is the whole point.

When a Port Stops Answering, We Tell You Why

This is where CleverUptime stops being a dashboard. When a port that should answer goes quiet, a plain port monitor says “443 is down” and leaves you to it. We do the next step for you: because the agent is also watching what's running inside the box, we correlate the dead port with the service behind it. So instead of a red dot, you get the actual sentence — the web server process died, here's how to confirm it with systemctl status, and here's the command to bring it back.

A closed port is a symptom; a stopped service is the cause. Tying the outside view to the inside view is the only way to get from one to the other without you SSHing in at 2 a.m. to play detective. Every alert links to a knowledge-base article that teaches the fix, so the second time it happens you barely need us — which is, honestly, the goal.

The whole point

Anyone can tell you a port stopped answering. The hard part — the part that saves your evening — is the diagnosis: which service died, how to confirm it with systemctl, and the one command that brings it back. That's the difference between an alarm and an answer.

One Small Script, Then It Watches Both Sides

Setup is one short bash script you run on the server — short enough to read in a couple of minutes, because you should never run code on your box you don't understand. It reads what's listening locally and reports home; from there CleverUptime spins up the matching external probes on its own. You end up with both views in one place: what ss sees from the inside, and what the internet sees from the outside, reconciled into a single picture of whether your server is truly reachable.

Ports are one face of the machine. The same setup quietly stands up uptime monitoring so you know it's actually up, SSL certificate monitoring so a cert on 443 never expires on your watch, DNS monitoring for the records that point the world at you, and page speed monitoring for when it's up but slow. It all rolls into the same server monitoring dashboard, with the root-cause analysis that turns every alert into a fix.

Sure the port’s open — but is the right one open, and nothing else?

CleverUptime probes your ports from the outside, knows which ones should answer because it sees what's running inside, and tells you which service died — or which one is exposed — in plain language.

Check your server →