How to Set Up TCP Uptime Monitoring

What is a TCP Check?

A TCP check opens a TCP connection from Xitoring's global probing nodes to a host and port. If the three-way handshake completes, the service is treated as up; if it doesn't, the check fails. TCP checks don't speak any application protocol, which makes them the universal fallback for anything that listens on a port.

Use TCP checks for:

Databases (MySQL 3306, PostgreSQL 5432, MongoDB 27017, Redis 6379)
Message queues (RabbitMQ 5672, Kafka 9092)
SSH (22) and custom shell access ports
Game servers, streaming endpoints, and any custom binary protocol
Any service for which Xitoring doesn't ship a dedicated check type

What Gets Monitored

TCP handshake success — connection opens within the timeout
Response time — handshake duration from each probing node
Geographic availability — service reachable from each region
Port-level reachability — confirms both the host and the service are alive

Prerequisites

A reachable host (public IP or hostname)
The TCP port the service listens on
Firewall rules allowing TCP from Xitoring's probing IP ranges to that port
For services behind a load balancer, the public-facing endpoint

How to Set Up a TCP Check

Step 1: Create the Check

Log in to your Xitoring Dashboard
Go to Uptime → Add Check
Select TCP as the check type

Step 2: Configure the Connection

Enter the hostname or IP (e.g., db.example.com)
Set the port (e.g., 5432 for PostgreSQL)
Set the check interval (30 seconds to 15 minutes)
Set the timeout (default: 30 seconds)

Step 3: Choose Probing Nodes

Select at least 3 probing nodes in regions where clients connect from. For internal-only services, target a public proxy or use a private probe node.

Step 4: Assign Notifications

Under Triggers, attach a notification role.

Step 5: Save and Verify

Save the check. The first probe runs immediately.

Setting Up Triggers

Common alerting rules:

Connection refused — service stopped or crashed
Connection timed out — host unreachable or firewall dropping packets
Slow handshake — response time exceeds threshold (often signals network or kernel pressure)
Confirmed down — failures across multiple probing nodes

Tips

A TCP check confirms the listener is up — not that the service works. PostgreSQL's port can be open while replication is broken. Pair TCP with an application-level check when possible
Don't expose admin ports to the public internet just to monitor them. Use a private probing node, an SSH bastion, or run an HTTP health endpoint that proxies the check internally
Use TCP for any TLS service you don't have a dedicated check for — the handshake confirms reachability even if Xitoring can't speak the application protocol
Watch response time on the probe closest to your users — a sudden jump usually means network congestion or kernel-level resource pressure
Avoid TCP checks on ephemeral high ports — services that pick a port at random can't be reliably monitored this way