TCP monitoring
Monitor port reachability of any host with a raw TCP connect check, without HTTP or protocol inspection.
TCP monitors check whether a given host and port accept a TCP connection. Unlike HTTP monitors, they do not send or inspect any protocol payload. The check only verifies that 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 on the same prober fleet as ping and HTTP monitors, with the same interval, region, and alerting options. A workspace without multi_region is dispatched to one effective region. When multi_region is enabled, you can select several currently available regions in the monitor form.
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. The monitor form enforces the current workspace minimum. |
| 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
TCP monitors count toward the workspace monitor quota. Check frequency and the number of active regions use the same Uptime entitlements as other monitor types. See the pricing page for current limits.
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.
Was this page helpful?