TCP monitoring
Monitor port reachability of any host with a raw TCP connect check — no HTTP or protocol inspection.
TCP monitors check whether a given host and port accept a TCP connection. Unlike HTTP monitors, they don't send or inspect any protocol payload — the check only verifies the port is open and reachable.
How it works
TCP connect check, from the prober to the target port
TCP monitors do not send any data once connected and do not read a response. They confirm only that something is listening on the port, not that the service behind it is behaving correctly.
TCP monitors run from the same multi-region prober fleet as ping and HTTP monitors, with the same interval, region, and alerting options.
On Uptime Free, checks run from a single region (Nuremberg by default). Every paid Uptime plan can send the same check from multiple regions in parallel:
See Monitors, Prober regions for how multi-region results combine into one status.
TCP monitors require the target port to accept external connections. If a firewall or security group blocks the prober's IP ranges, the check fails even if the service is healthy internally.
Configuration
| Field | Description |
|---|---|
| Host | Hostname or IP address to connect to, e.g. db.example.com |
| Port | TCP port to connect to, 1-65535, e.g. 5432 |
| Check interval | How often to attempt the connection. Minimum: 120s on Free, 60s on S, 30s on M, 15s on L |
| Alert threshold | Consecutive failures before triggering an alert. Default: 2 |
The monitor type is fixed once the monitor is created, the same as ping monitors.
Use cases
- Databases and message brokers — confirm PostgreSQL, MySQL, Redis, or similar services are accepting connections without needing an HTTP health endpoint.
- Mail and other non-HTTP services — verify a port is open for services such as SMTP or a custom TCP protocol.
- Firewall and load balancer changes — catch a port that was accidentally closed after a network or security group change.
Plan availability
| Feature | Free | S | M | L |
|---|---|---|---|---|
| TCP monitors | 50 total | 100 total | 500 total | 2000 total |
| Minimum check interval | 120s | 60s | 30s | 15s |
| Multi-region TCP | Single region | ✓ | ✓ | ✓ |
For current limits and pricing, see the pricing page.
Limitations
- No payload or protocol inspection. A TCP monitor only confirms the port accepts a connection. It cannot verify that the service behind the port is responding correctly, authenticating, or returning expected data.
- No private IPs. HowlOps probers run from cloud infrastructure and can only reach publicly routable hosts and ports.
- No SSL/TLS validation. A TCP monitor does not inspect certificates, even on a port that happens to speak TLS. Use an HTTP monitor with SSL monitoring enabled for certificate-expiry checks.
FAQ
Can I monitor a private/internal port? No. HowlOps probers can only reach publicly routable IPs and ports.
Does a successful TCP check mean the service is healthy? It means the port is accepting connections. It does not verify the application behind the port is functioning correctly. For that, use an HTTP monitor against a health endpoint where one exists.
Related
Was this page helpful?