If a port closes, your users feel it before your dashboard does

TCP monitoring tests network connectivity by performing a TCP handshake (SYN → SYN-ACK → ACK) against a target host and port at regular intervals. PulseStack™ initiates a connection from 7 global locations, measures the time to complete the three-way handshake, and records whether the connection succeeded, was refused, or timed out. This tells you whether a remote service is reachable, how fast the network path is, and whether firewalls or routing issues are blocking traffic.

Ping uses ICMP echo requests to test basic network reachability. It tells you the server is powered on and connected to the network, but nothing about whether specific services are running. TCP monitoring connects to a specific port, confirming that the operating system is up AND the application behind that port is accepting connections. A server can respond to pings while every service on it is crashed. TCP monitoring catches what ping monitoring misses.

The handshake duration reveals network health at multiple levels. A fast handshake (under 10ms on the same continent) means the network path is clean and the server is processing connections quickly. A slow handshake (100ms+) suggests network congestion, overloaded servers, or suboptimal routing. A failed handshake means either the service is down (connection refused), a firewall is blocking the port (connection timeout), or there is a DNS or routing failure (host unreachable).

TCP is a connection-oriented protocol with a guaranteed handshake, making it easy to monitor: either the connection completes or it does not. UDP is connectionless with no handshake, so there is no universal way to confirm a UDP service is running without application-specific probes. PulseStack focuses on TCP monitoring because it covers the vast majority of infrastructure services including web servers, databases, email, SSH, and APIs. DNS is a notable exception that uses both UDP and TCP.

For production services, 30-second intervals provide near-real-time failure detection. The free plan supports 3-minute intervals, which catches outages within 3 minutes. For less critical services or development environments, 5-minute intervals reduce noise while still catching sustained failures. The right interval depends on your recovery time objective: if your SLA requires detection within 1 minute, you need 30-second checks.

Yes. Connection time trends are an early warning system. When a database starts running out of connections, the handshake takes longer as the OS queues incoming SYN packets. When a server approaches CPU saturation, TCP accept times increase. PulseStack tracks connection time for every check and can alert you when response times exceed configurable thresholds, letting you intervene before the service stops accepting connections entirely.

A refused connection (TCP RST response) means the server received your SYN packet and actively rejected it because nothing is listening on that port. This happens quickly, usually within milliseconds. A timeout means no response was received at all, typically because a firewall dropped the packet silently. Refused connections usually indicate a stopped service. Timeouts usually indicate a firewall or network routing issue. The diagnostic approach differs significantly for each.

Network issues are often localised. A routing problem between one data centre and your server does not mean your service is down globally. PulseStack checks from 7 locations and uses consensus logic: if only one location reports a failure while others succeed, it flags a regional issue rather than triggering an outage alert. This dramatically reduces false positives while still catching real failures that affect all locations.

PulseStack monitors any host reachable from the public internet. For internal services behind firewalls, you would need to allow inbound TCP connections from our monitoring IP ranges on the specific ports you want checked. Alternatively, you can monitor the health of internal services indirectly by checking the public-facing endpoints that depend on them, since an internal database failure typically causes visible HTTP errors.

Monitor every port that runs a service in your application dependency chain. Start with databases (MySQL 3306, PostgreSQL 5432, MongoDB 27017), caches (Redis 6379, Memcached 11211), web servers (HTTP 80, HTTPS 443), email (SMTP 25/587), and remote access (SSH 22). Then add any custom application ports. The goal is to detect a failure at any layer before it cascades into a visible outage.

The free tool on this page initiates a TCP connection from our server to the host and port you specify. It performs a standard three-way handshake, measures the connection time in milliseconds, and reports whether the port is open (accepting connections), closed (actively refusing), or filtered (no response, likely firewalled). No account required, no rate limits for reasonable use.

Absolutely. One of the most common uses is verifying that firewall rules are correctly configured after changes. After a network team updates security groups, iptables rules, or cloud provider firewalls, TCP monitoring confirms that intended ports remain open and that ports meant to be blocked are actually closed. Many teams trigger ad-hoc TCP checks immediately after firewall changes to validate their work.