TCP monitoring: is the service actually taking connections?
A TCP check does the first thing every client does: open a connection. If the three-way handshake completes, something is listening and accepting work. If it’s refused or hangs, your users are already getting errors.
Example check · demo data
TCP monitoring checks a service by opening a TCP connection to its host and port and confirming the handshake completes within a timeout. A refused or timed-out connection means the service isn’t accepting traffic.
What each TCP result tells you
The difference between refused and timed out is the most useful clue in the first minute of an incident: refused means “the machine is there, the app isn’t”; timed out points at the network or the whole host.
| Result | What happened | Usual cause | Connected | Connection refused | Timed out | Slow connect | Connection reset later |
|---|---|---|---|---|---|---|---|
| Handshake completed | Service is listening | ||||||
| The host answered with a reset (RST) | Process crashed or not listening on that port; host itself is up | ||||||
| No answer at all | Firewall dropping packets, host down, or network path broken | ||||||
| Handshake completed, but late | Overloaded host, full accept queue, or distance | ||||||
| Accepted, then dropped | Load balancer with no healthy backends; proxy limits |
How StatusEagle runs a TCP check
TCP monitoring vs port monitoring vs HTTP
In StatusEagle, TCP checks are the TCP side of port monitoring. For UDP services, see UDP monitoring. If the service speaks HTTP, an HTTP check goes further: it proves the application answers correctly, not just that a socket is open.
Watch out for load balancers
A load balancer can accept TCP connections even when every server behind it is down; it completes the handshake, then resets or returns an error. For services behind a load balancer, pair the TCP check with an application-level check (HTTP status, or a keyword on the response) so a healthy-looking socket doesn’t hide a dead backend.
Related monitoring
Pair these monitoring checks to ensure complete stack coverage.
Frequently asked questions
Still deciding? Start monitoring free and verify your first service in ~2 minutes.
Checking a service by opening a TCP connection to its port and confirming the handshake completes, alerting when connections are refused or time out.
Your first monitor takes about two minutes.
Free plan: 10 monitors, 3 locations, 1 status page. No credit card.