StatusEagle
Port monitoring

Port monitoring for the services that don’t have a web page

Your database, mail server and SSH don’t answer HTTP. A port monitor opens a connection to the port they listen on and tells you, within a minute, when it stops being accepted.

Port · db.example.com:5432
Live check snapshot
Active
ProtocolTCP
Connect time11 ms
Timeout10 s
ResultConnection accepted

Example check · demo data

In brief

Port monitoring checks whether a network service is accepting connections on a specific TCP or UDP port, such as 5432 for PostgreSQL or 587 for SMTP, and alerts you when it stops responding.

1

Common ports worth monitoring

Only expose a database port to monitoring if it’s already reachable from outside, and restrict it to StatusEagle’s addresses link IP list. Never open a database to the internet just to monitor it. Use a heartbeat from inside the network instead.

PortServiceWhy monitor it2225 / 465 / 587534433306543263791194 / 51820
SSHYour way in when everything else is broken
SMTPPassword resets, receipts and alerts depend on outbound mail
DNSIf your own resolvers stop answering, everything looks down
HTTPSA lightweight check below the website monitor
MySQL / MariaDBThe app can’t work without it
PostgreSQLSame, and connection limits are a common failure
RedisSessions and queues often live here
OpenVPN / WireGuardRemote staff lose access silently
2

How StatusEagle checks a port

TCP: the monitor attempts a full connection (the handshake). Accepted means up; refused or timed out means down.
UDP: the monitor sends a datagram and waits for a response. See UDP monitoring for how that differs.
You set the connection timeout, so a slow-but-alive service isn’t mistaken for a dead one.
Failures are retried, then confirmed from another location, before anyone is alerted.
3

Port monitoring vs ping vs HTTP

Layering them makes incidents faster to read: ping green, port red means the host is fine but the service crashed.

PingPortHTTPProves the host is reachableProves the service is listeningProves the service responds correctlyWorks for databases, mail, SSH
YesYesYes
NoYesYes
NoNoYes (status code, keyword)
PartlyYesNo
4

Tips from running this ourselves

Monitor the port your app actually connects to. If traffic goes through a connection pooler like PgBouncer (usually 6432), check that, not just 5432.
Give databases a slightly longer timeout than web services. Under load they accept connections slowly before they stop accepting them at all.
Name monitors after the service, not the port: “orders-db (Postgres)” reads better in a 3 AM alert than “10.0.4.12:5432”.
COMPLEMENTARY CHECKS

Related monitoring

Pair these monitoring checks to ensure complete stack coverage.

FAQ

Frequently asked questions

Still deciding? Start monitoring free and verify your first service in ~2 minutes.

Port monitoring checks whether a service is accepting connections on a given TCP or UDP port, and alerts you when it stops.

GET STARTED IN MINUTES

Your first monitor takes about two minutes.

Free plan: 10 monitors, 3 locations, 1 status page. No credit card.