Opens a real connection
We attempt an actual TCP handshake to your host and port on a schedule. If the connection is accepted, the port is open. If it is refused or times out, it is not.
Port monitoring
PulseStack opens a real TCP connection to your host and port on a schedule, confirms it is open and accepting connections, and times how long the handshake takes. When it stops, and a second location confirms it, you get alerted. No guesswork, no waiting for a customer to complain.
14-day trial on every paid plan - Port checks from 60 seconds, down to 30 on Pro and above - No card needed to start
Live TCP connection attempt - exactly what PulseStack does on every check.
Live TCP connection check - open or closed, and how fast it answered
PulseStack does one thing here and does it precisely: it tests connectivity. It opens a TCP socket to the host and port you specify, waits for the connection to be accepted, and records the time it took. That is the whole job - open or closed, fast or slow.
We attempt an actual TCP handshake to your host and port on a schedule. If the connection is accepted, the port is open. If it is refused or times out, it is not.
Every check records how many milliseconds the handshake took, so you can see a port getting sluggish long before it drops entirely.
When a port stops accepting connections and the failure is confirmed from at least two locations, PulseStack fires an alert to the channels you have chosen.
This is connectivity and latency monitoring, not service fingerprinting. PulseStack tells you a port is open and accepting connections and how quickly it answered. It does not identify or fingerprint the service running behind the port. If you want content-aware checks, pair it with an HTTP or API monitor.
A closed port is rarely just one closed port. It is a queue backing up, a login page spinning, and a support inbox filling. Here is the chain you are trying to break.
Port 5432 or 3306 refuses new sockets after a crash or a maxed connection pool. Your app throws errors it was never designed to show.
RabbitMQ on 5672 or Redis on 6379 stops listening. Jobs pile up in memory, nothing is processed, and no HTTP check ever notices.
Port 25, 465 or 587 stops answering and outbound email silently fails. Password resets and receipts never arrive.
A custom TCP service on a non-standard port stops accepting players or viewers. There is no web page to load, so nothing else would catch it.
Under the hood a port check is simple, and that is the point. It is the same thing you would do by hand at a terminal, run on a schedule from multiple locations, recorded, and turned into an alert once a change is confirmed.
check db.acme.io:5432
connecting to db.acme.io:5432 ...
OPEN - connection accepted in 24 ms
check queue.acme.io:5672
connecting to queue.acme.io:5672 ...
CLOSED - refused from 2 of 3 locations, re-test failed
alert dispatched: Slack, PagerDuty
Add your first port monitor in under a minute and let PulseStack keep the connection honest.
No agent to install on your server. PulseStack connects from the outside, exactly as a real client would.
Point PulseStack at any host and TCP port you want kept open.
From 60 seconds on Starter, down to 30 seconds on Pro and above.
Every failure is re-tested and must be seen from at least two of three locations before it counts as an outage.
Route to Slack, PagerDuty, SMS or any of eight channels.
A port check is never sold on its own. It arrives with the full PulseStack monitoring toolkit.
Most outages are not caused by a single failing thing. Combine port checks with the rest of the PulseStack toolkit and watch the whole stack from one dashboard.
Confirms a TCP port is open and accepting connections.
Checks a host answers on a port and times the handshake.
Watches a URL for status, response time and content.
Flags when expected text vanishes from a page.
Monitors JSON endpoints with custom request headers.
Expects a ping from your job and alerts when it goes quiet.
Alerts when a certificate nears expiry or turns invalid.
Alerts when a record no longer holds the value you expect.
Alerts when a domain registration is close to expiring.
They overlap, but they answer different questions. Here is the honest breakdown.
| Question you are asking | Port monitor | HTTP monitor | TCP Ping |
|---|---|---|---|
| Is the port accepting connections? | Yes | Only if it is a web port | Yes |
| How fast is the handshake? | Yes, in ms | Measures full response time | Yes, in ms |
| Is the web page returning 200? | No | Yes | No |
| Does the service identify itself? | No | Reads content and headers | No |
| Works on databases and brokers? | Yes | No | Yes |
Keep databases, brokers and internal services honest without waiting for an app-level error to surface the problem.
Watch the ports your product depends on - cache, queue, mail - so a silent dependency failure never becomes a public incident.
Monitor custom TCP services on non-standard ports where there is no web page for other tools to check.
Let PulseStack keep checking the connection so you hear about a closed port first.
When a port failure is confirmed from at least two locations, PulseStack pushes to any of eight native channels. SMS comes as an add-on, and is included on the Team and Enterprise plans.
TCP port monitoring connects to a specific port number on a server at regular intervals to verify that the service behind it is accepting connections. Unlike ping monitoring which checks network reachability, port monitoring confirms that a specific application (like MySQL on port 3306 or SSH on port 22) is actually running and responding. If the connection fails, you know the service is down even if the server itself is still online.
Website monitoring sends HTTP requests and checks response codes, headers, and content. Port monitoring operates at a lower level, testing whether a TCP connection can be established on a specific port. Many critical services like databases, mail servers, Redis caches, and SSH do not serve web traffic. Port monitoring is the only way to verify these services are running. Most teams use both: HTTP monitoring for web-facing services and port monitoring for backend infrastructure.
Monitor every port that runs a service your applications depend on. Common choices include: MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379), Elasticsearch (9200), SSH (22), SMTP (25, 587), DNS (53), and any custom application ports. A good rule of thumb is to trace your application's dependency chain and monitor every service endpoint it connects to.
It can show it. PulseStack™ measures connection time for every port check and charts it per location. When a service is struggling (high load, memory pressure, connection pool exhaustion), the TCP handshake takes longer, so a rising line is an early warning you can act on before the service stops accepting connections entirely. Alerts themselves fire when the port stops accepting connections, not on connection time.
Port checks run every 60 seconds on Starter and as often as every 30 seconds on Pro, Team and Enterprise, from each monitoring location. The free plan covers HTTP monitors only, checked every 5 minutes. Each check attempts a TCP connection to the specified port and measures connection time, recording whether the connection succeeded, timed out, or was refused.
A closed port actively refuses the connection with a TCP RST packet, meaning the server is reachable but no service is listening on that port. A filtered port does not respond at all (the connection times out), which usually means a firewall is blocking traffic. PulseStack™ distinguishes between these states so you can diagnose whether the problem is with the service itself or with network/firewall configuration.
PulseStack™ monitors ports that are accessible from the public internet. For internal services behind a firewall, you would need to open the port to our checkers, or use a heartbeat monitor instead: a small scheduled job inside your network tests the service and checks in with PulseStack™, so no inbound port has to be opened. Contact our team for guidance on firewall configuration.
When a single monitoring location reports a port as unreachable, it could be a routing issue between that location and your server rather than an actual service failure. PulseStack™ checks from 3 locations (London, New York and Sydney) simultaneously and uses consensus logic. If only one location fails while the others succeed, it is not treated as a service outage: a monitor is only marked down when at least two of the three locations fail, and a failed check is re-tested a few seconds later. That dramatically reduces false positives.
Yes. You can create separate monitors for every port on a server. It is common to monitor 5 to 10 ports per server: SSH, the web server, the database, the cache layer, and any background worker ports. Each monitor has its own alert configuration and check interval, so you can prioritise critical services with faster checks.
All 8 native alert channels are available: email, SMS, Slack, Discord, Microsoft Teams, Telegram, PagerDuty and webhooks, and Zapier connects through webhooks. You can configure different channels per port monitor, and failed checks are re-tested and confirmed from at least two locations so transient connection blips do not trigger unnecessary alerts.
Start free, add a port monitor in a minute, and let PulseStack tell you the moment a connection stops being accepted. No card needed to begin.