Network Port Monitoring
More than just the web. Track the availability of your databases, mail servers, and custom TCP services with instant response to their failure.
Comprehensive service oversight
Many critical applications don't run on standard HTTP. Databases like PostgreSQL or MySQL, email servers (SMTP/IMAP), or VPN services require a specific monitoring approach. Pulsitor Port Monitoring verifies low-level TCP connectivity to a selected port on your server. This type of check is invaluable for verifying that a service is ready to accept connections and helps detect firewall issues or background process crashes that web monitoring might miss. You pick the protocol for every monitor yourself, so a check is never guessed from the port number.
Protocol-aware port checks
What makes Pulsitor powerful out of the box.
You name the protocol
You choose the protocol for every monitor — TCP, TCP with TLS, HTTP, HTTPS, or a UDP probe.
A timeout you control
You can precisely define connection timeouts, helping you identify overloaded servers.
Private nodes on the way
We are preparing support for private nodes, allowing you to monitor services even inside your local network.
One port, eight kinds of check
The same host and port can mean eight different things. Say which one you mean and the check tells you the truth — including over UDP, where there is no connection to lean on.
TCP
A plain connection handshake. It answers the one question that matters for a database, a queue or a game server: does the port accept connections at all?
TCP + TLS
The connection plus a completed TLS handshake. Made for IMAPS, SMTPS and anything behind TLS on a non-standard port — a certificate the server cannot present fails the check.
HTTP
A real GET request, on whatever port your application listens on. An app on :3000 or :9000 is checked like a website, not like a bare socket.
HTTPS
The same request over TLS. Port 8443 is no longer a special case — the protocol is the one you chose, not the one the port number suggested.
UDP (no probe)
For custom UDP services. An empty datagram proves a port is closed when the host rejects it; a port that stays silent may just as well be a healthy service that only answers its own clients, so it counts as up. We say that plainly instead of inventing certainty UDP cannot give.
DNS (UDP)
A real DNS query your resolver answers. UDP has no handshake to lean on, so the answer itself is the proof that the port is open and the service alive — and its round trip is a genuine response time.
NTP (UDP)
A time request to your NTP server, matched against the answer that comes back. The check every machine on your network depends on and nobody watches.
STUN (UDP)
A binding request to a STUN or TURN server — the UDP side of every WebRTC deployment. Also the neatest way to make a UDP service of your own answerable: put a small STUN responder next to it.
Wide monitoring scope
Anything that speaks over a socket
Track anything that communicates over the network — from DB servers to IoT devices.
Network problems, before the cascade
Catch network layer issues before they cause cascading failures in your applications.
Nothing to install on your side
Configuration is straightforward and requires no software installation on the monitored side.
Port monitoring at a glance
Eight protocols, one port, no guessing.
| Property | Value |
|---|---|
| Protocols | TCP, TCP + TLS, HTTP, HTTPS, UDP, DNS over UDP, NTP over UDP, STUN over UDP |
| Port range | 0 to 65535 |
| Timeout | 1 to 60 seconds |
| Check interval | 15 to 180 seconds, depending on plan |
| Before an incident opens | Confirmed from more than one of 5 regions |
| Notification channels | 14 |
| Available on | All plans, Free included |
Port monitoring questions
What a port check can and cannot tell you.
Which protocols can a port check speak?
Eight: plain TCP, TCP with TLS, HTTP, HTTPS, a bare UDP probe, and real DNS, NTP and STUN queries over UDP. You pick one per monitor — it is never guessed from the port number.
How does a UDP check work without a connection?
For DNS, NTP and STUN the probe sends a real query and waits for a real answer, and that answer is the proof the service is alive. A bare UDP probe instead reads the ICMP rejection a closed port sends back.
Can I monitor a database or a mail server?
Yes. PostgreSQL, MySQL, SMTP, IMAP, Redis, a game server — anything that accepts a connection on a port reachable from the internet.
What port numbers and timeouts are allowed?
Any port from 0 to 65535, with a connection timeout you set between 1 and 60 seconds.
Is port monitoring available on the free plan?
Yes. Port checks work on every plan, the Free one included.
Quick start for port monitoring
Enter the IP address or domain and the port number you want to keep under watch, then pick the protocol the service speaks.
Set check frequency according to the importance of the given infrastructure.
Save the monitor and rest easy knowing your backend services are constantly guarded.