TCP Port Test — Is the Port Actually Open
This attempts a connection to a specific port on a specific host and reports what happened: connected, refused, or timed out. Those three outcomes mean genuinely different things, and distinguishing between them is one of the fastest ways to cut a problem in half.
Why run it
The three responses map to three different teams. Connection refused means something answered and actively declined — the host is up and the service is not listening, so it is an application problem. A timeout means nothing answered at all, which points at a firewall or routing issue between you and it. A successful connection means the network path and the listener are both fine and the problem is above the transport layer entirely. Knowing which of the three you have takes seconds and saves the hour usually spent with everyone investigating in parallel.
Why automate it
Firewall rules and security groups change constantly, and they change for reasons unrelated to the service they break — a policy tightened globally, a rule cleaned up because it looked unused. The service that depended on it fails at some later point, and by then the change is not obviously connected. A scheduled connection test on the ports that matter catches the closure when it happens rather than when something next tries to use it, which for infrequent paths like backup targets or failover links can be months later.
What it gives you
An immediate answer to whether the network or the application is at fault, which is the fork every reachability investigation starts with. Monitored, it protects the rarely used paths that only fail when you urgently need them.