Verify that server ports are open and hosts are reachable. This guide covers TCP port monitoring (databases, mail servers, SSH), Ping/ICMP (network-level reachability), and when to use each vs HTTP monitors for UK services.
TCP port monitoring • Ping (ICMP) monitoring • HTTP vs TCP vs Ping • Intervals, retries and timeouts • Practical examples • FAQ
A TCP monitor checks whether a specific port on a server is open and accepting connections. It doesn’t care what happens after the connection is established — it simply verifies the port responds. Ideal for services that don’t speak HTTP: databases, mail servers, FTP, SSH, custom applications.
Common TCP monitoring:
Good to know: TCP confirms the port is open but doesn’t verify the service behind it is functioning. A database port might accept connections while the database itself is in a crash-recovery state. For deeper checks, use Uptime Kuma’s dedicated database monitor types.
A Ping monitor sends ICMP echo request packets to a hostname and waits for a reply. Host responds = up; no response within timeout = down. Simplest network-level check — tells you the machine is reachable, without testing any specific service.
Typical Ping use cases:
Important: many firewalls and cloud providers block ICMP by default. If Ping shows your server as down but services work fine, the issue is likely a firewall rule blocking ICMP packets. Use a TCP monitor on a known-open port instead (443 for HTTPS, 22 for SSH).
| Feature | HTTP(s) | TCP | Ping |
|---|---|---|---|
| What it checks | Full HTTP response — status, body, headers, cert | TCP port accepts connection | Host replies to ICMP |
| Best for | Websites, APIs, web apps | Databases, mail, custom services | Servers, routers, devices |
| Content check | Yes (keyword, JSON) | No | No |
| SSL cert | Yes (auto for HTTPS) | No | No |
| Limitations | HTTP/HTTPS only | Doesn’t verify service health | ICMP may be blocked |
Best practice: HTTP for web traffic. TCP for non-HTTP services where you need specific port verification. Ping only when you need host-on-network confirmation AND you know ICMP is allowed.
Shared settings across TCP, Ping and other monitor types:
mail.mybusiness.co.uk, Port: 993192.168.1.1 (or router’s public IP)db.mybusiness.co.uk, Port: 5432With 3 retries, brief connection hiccups don’t cause false alerts.
TCP and Ping monitoring included
Unlimited monitors of all 16+ types on SmartXHosting Uptime Kuma Hosting — HTTP, TCP, Ping, DNS, database, Push — from £1/month.
View Uptime Kuma HostingQ: TCP vs Ping — which should I choose?
A: TCP confirms a specific service is running on a port. Ping confirms the machine is on the network. TCP is more useful for most service monitoring; Ping for raw network reachability.
Q: Why does my Ping fail when server is up?
A: Firewall or cloud provider blocks ICMP. Use a TCP monitor on port 443 or 22 instead.
Q: Which TCP ports for common UK services?
A: 443 HTTPS, 3306 MySQL, 5432 PostgreSQL, 993 IMAP, 587 SMTP submission, 22 SSH, 21 FTP.
Q: How many retries for TCP/Ping?
A: 1–3 for production. Prevents false alerts from brief network hiccups.
Q: Can I monitor a service inside my private network?
A: Only if Uptime Kuma has network access. For internal-only services, self-host Uptime Kuma on your own network or use a VPN tunnel.