Every service your application depends on communicates over TCP. When a handshake fails, the service is unreachable. TCP Pulse monitors every connection, measures every handshake, and alerts you the instant a link in the chain breaks. Combine with port monitoring for complete service-layer visibility.
Client
192.168.1.50
Server
db-prod:3306
Client initiates connection
Server acknowledges
Connection established
Dependency awareness
Modern applications are a web of interconnected services. Your load balancer forwards to application servers. Those connect to databases, caches, and search engines. Each connection is a TCP socket. Each socket is a potential point of failure.
TCP monitoring maps these dependencies. When Redis on port 6379 goes dark, you know before the database gets overloaded. When Elasticsearch on 9200 becomes unreachable, you know before search breaks. The topology view shows which connections are healthy and which are failing, in real time.
This is infrastructure monitoring at the network layer. Above it, HTTP monitoring checks your applications. Below it, ping monitoring checks your servers. TCP monitoring fills the critical gap between.
TCP monitoring detects service failures at the network layer before they cascade through your application stack.
Free tool
Test whether any TCP port is open, closed, or filtered. No account required.
Test connectivity to any host and port
For continuous monitoring with automated alerts, create a free account with 50 monitors included.
Would you know in 30 seconds? Or would your users tell you 30 minutes later?
Different protocols serve different purposes. TCP monitoring covers the widest range of production services.
Best for services
Transmission Control Protocol
Connection
Connection-oriented
Handshake
3-way (SYN/SYN-ACK/ACK)
Used for
Web, databases, email, SSH
Monitoring
Port check confirms service is running
User Datagram Protocol
Connection
Connectionless
Handshake
None
Used for
DNS queries, video streaming, VoIP
Monitoring
No handshake, harder to verify
Internet Control Message Protocol
Connection
Network layer only
Handshake
Echo request/reply
Used for
Ping, traceroute, network diagnostics
Monitoring
Tests reachability, not services
TCP deep dive
A TCP connection has four phases: establishment (the three-way handshake), data transfer, idle keepalive, and termination. Each phase can fail in different ways that affect your application differently.
During establishment, failures manifest as connection timeouts or refusals. During data transfer, failures cause broken pipes and reset connections. During idle periods, connections can silently die when intermediate firewalls or load balancers close inactive sockets without notification.
TCP monitoring focuses on the establishment phase because it is the fastest and most reliable indicator of service health. If a service cannot complete a handshake, it cannot serve any traffic. The connection time directly measures how quickly the service processes the SYN backlog.
For complete application health, combine TCP checks with API monitoring that validates data transfer works correctly, and HTTP monitoring that checks application responses end-to-end.
Performance tuning
The default TCP connection timeout on most operating systems is 75 seconds. For monitoring, this is far too long. PulseStack uses a configurable timeout (default 10 seconds) to detect failures quickly without triggering false positives on congested networks.
Set response time thresholds based on your geography and service requirements. PulseStack alerts you when connection times exceed your threshold, giving you early warning of performance degradation before connections start failing entirely.
Everything you need to monitor TCP connections at scale, from a single server to a global fleet.
Every check performs a full SYN/SYN-ACK/ACK handshake, confirming the service is genuinely accepting connections, not just the server responding to pings.
Handshake duration is measured to the millisecond. Track trends over time and get alerted when latency exceeds your configured thresholds.
Distinguish between a stopped service (RST), a firewalled port (timeout), and a DNS resolution failure. Each requires a different remediation.
Check from New York, San Francisco, Toronto, London, Frankfurt, Singapore, and Bangalore. Consensus logic eliminates false alarms from regional issues.
Detect service failures within 30 seconds. For critical infrastructure like production databases, this means recovery starts in under a minute.
Email, SMS, phone, Slack, Discord, Teams, Telegram, PagerDuty, OpsGenie, webhooks, Zapier, and more. Escalation policies for critical services.
Real scenarios where TCP monitoring detects the problem minutes before any other monitoring type.
Your MySQL server hits max_connections. New handshakes queue in the SYN backlog, and connection time spikes from 3ms to 800ms.
Detection: TCP monitoring alerts on response time threshold before any HTTP 500 errors appear.
Detected 2 min earlier before HTTP monitoringA security team update accidentally blocks port 6379 in a security group. Redis becomes unreachable from application servers.
Detection: TCP check to port 6379 immediately returns filtered state instead of open.
Detected 30 sec before HTTP monitoringA new deploy causes PostgreSQL to crash during startup. The process exits silently. Port 5432 transitions from open to closed.
Detection: TCP monitoring detects connection refused within one check interval.
Detected 30 sec before HTTP monitoringYour Nginx TLS terminator slowly leaks memory. At 95% utilisation, new TCP handshakes on port 443 take 5+ seconds.
Detection: Connection time threshold alert fires as handshake times degrade.
Detected 5 min earlier before HTTP monitoringInternal DNS stops resolving db-primary.internal. Applications cannot establish TCP connections to the database.
Detection: TCP checks using hostname detect resolution failure immediately.
Detected 30 sec before HTTP monitoring50 monitors free forever. Upgrade when you need faster checks or more capacity.
Most popular
£29/month
All plans include multi-location checks, incident management, and public status pages. Full plan comparison →
TCP monitoring covers the connection layer. Complete your stack with these.
Everything you need to know about TCP monitoring.
Monitor every TCP connection across your infrastructure. Free for 50 monitors, no credit card required.
Start TCP monitoring free