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
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. The instant it stops, 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 Enterprise - No card on the free plan
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.
The moment a port stops accepting connections and crosses your failure threshold, 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 the second the answer changes.
$ pulsestack check --host db.acme.io --port 5432
connecting to db.acme.io:5432 ...
OPEN - connection accepted in 24 ms
$ pulsestack check --host queue.acme.io --port 5672
connecting to queue.acme.io:5672 ...
CLOSED - connection refused after 3 attempts
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 paid plans, down to 30 seconds on Enterprise.
Choose how many consecutive failures count as a real outage to cut noise.
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.
Watches records for unexpected changes.
Counts down to registration expiry before it bites.
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 hold the connection open so you hear about a closed port first.
When a port fails your threshold, PulseStack pushes to any of eight native channels. SMS and voice come as an add-on, and are 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.
Yes. PulseStack™ measures connection time for every port check. When a service is struggling (high load, memory pressure, connection pool exhaustion), the TCP handshake takes longer. By setting connection time thresholds, you can detect degradation and address the root cause before the service stops accepting connections entirely.
On paid plans, port checks run as frequently as every 30 seconds from each monitoring location. The free plan supports 3-minute intervals. 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 allow inbound TCP connections from our monitoring IP ranges on the specific ports you want monitored, or use a monitoring agent inside your network. 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 7 locations simultaneously and uses consensus logic. If only one location fails while others succeed, it is flagged as a regional network issue rather than a service outage, dramatically reducing false positives.
Yes. You can create separate monitors for every port on a server. Many customers 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 16+ alert channels are available: email, SMS, phone calls, Slack, Discord, Microsoft Teams, Telegram, PagerDuty, OpsGenie, webhooks, Zapier, and more. You can configure different channels per port monitor and set consecutive failure thresholds 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.