Port (TCP) monitor
The port monitor opens a TCP connection to a host:port and reports success if the connection completes within the timeout. Use it for databases, message queues, SSH, SMTP, and any custom service that isn’t HTTP.
Configuration
| Field | Type | Default | Notes |
|---|---|---|---|
| Host | hostname | — | Hostname or IP. Protocol/port/path are auto-stripped. |
| Port | integer | — | 1–65535. Required. |
| Timeout | seconds | 10 | 5–30. |
| Degraded threshold | ms | — | Optional. Slow connects return degraded. |
| IP versions | array | ["ipv4", "ipv6"] | Which families to test. Cloud runners are IPv4-only. |
Status mapping
| Outcome | Status |
|---|---|
| Connection completes inside the timeout and under the degraded threshold | up |
Connection completes but slower than degraded_threshold_ms | degraded |
| Connection refused, timeout, network unreachable | down |
Private & internal targets
Cloud checkers block connections to private or reserved addresses
(RFC 1918 ranges, localhost, link-local / cloud-metadata, CGNAT
and similar). A check against a blocked or unresolvable target
records an explicit down result with the block or DNS-failure
reason in the error message. To monitor internal services, use a
self-hosted runner.
The check does not send any application-layer data — it just verifies that something is accepting TCP connections on the port. For protocol-level health (e.g. “the Postgres server actually responds to a query”), pair this with an HTTP check against an app endpoint that exercises the underlying service.