features · tcp / udp
Port monitoring for every service your users never see
Port monitoring opens a TCP or UDP connection to a specific port and alerts you when it stops accepting. AlertPing checks mail servers, databases and any custom port every 30 seconds from three regions, measuring connect time on each probe.
tcp · udp · any port 1–65535
alertping ▸ port checks · acme fleet
every 30 s
smtp mail.acme.dev:587 open 41 ms
pgsql db-eu.acme.net:5432 open 12 ms
redis cache.acme.net:6379 open 9 ms
ssh bastion.acme.net:22 open 28 ms
game eu1.acme.gg:27015/udp no reply
re-probing 27015/udp from IAD + SIN▌
what teams point it at
The services that fail quietly until payroll notices
Your website can be perfectly up while outbound mail piles up unsent or the database refuses new connections. A port check is the two-second test that each backing service still answers the door.
| Service | Typical port | Protocol | What a failed connect means |
|---|---|---|---|
| SMTP / mail | 25 · 465 · 587 | TCP | Password resets, receipts and invoices silently stop sending. |
| PostgreSQL / MySQL | 5432 · 3306 | TCP | Connection pool exhausted or the instance is down; the app fails next. |
| Redis / RabbitMQ | 6379 · 5672 | TCP | Sessions, caches and background jobs degrade before pages error. |
| SSH / bastion | 22 | TCP | Your own team is locked out right when they need to fix something. |
| Game / VoIP / custom | any 1–65535 | TCP or UDP | Players and callers drop; nothing shows on an HTTP dashboard. |
Connect-time latency
Every probe records how long the handshake took, per region. A database that accepts in 9 ms today and 240 ms on Friday is telling you something; the chart makes it obvious.
TCP and UDP
TCP checks confirm the full handshake. UDP checks send a datagram and watch for a response or an ICMP rejection, right for game servers, DNS and VoIP.
Any custom port
Nothing is hardcoded. Point a check at port 8080, 27015 or 3999 on any public host or IP; if your service listens there, we can watch it.
3-region confirmation
A refused connection from one region triggers instant re-probes from the other two. Only a 3-of-3 failure pages you, so a single flaky route never does.
part of the whole
One dashboard for the whole machine
Port checks pair naturally with our ping monitoring tool: ping tells you the host is alive, the port check tells you the service on it is too. Together they are the core of an agentless server monitoring tool, watching from the outside exactly the way your users connect.
When a port stops answering, downtime alerts reach your on-call by SMS, email, Slack or webhook in under 10 seconds after confirmation, with the port, region and connect error attached.
port check questions
Worth knowing up front
Can AlertPing monitor a database port directly?
Yes, if it is reachable from the public internet: PostgreSQL on 5432, MySQL on 3306, Redis on 6379, or any custom port. The check confirms the port accepts connections and records connect time from three regions.
Do UDP checks actually work? UDP has no handshake.
Yes, with a different method: we send a datagram and watch for either a service response or an ICMP port-unreachable rejection. Sustained silence from all three regions marks the check failed.
What about services on private networks?
Port checks need a publicly reachable host or IP. For jobs and services behind your firewall, cron heartbeat monitoring covers them: your service pings us, and we alert when it stops.
Watch the ports your business runs on
TCP and UDP checks every 30 seconds from 3 regions, with connect-time history and SMS alerts in every plan.