Skip to Content
CloudChecksTCP / port checks

TCP / port checks

When the thing you’re monitoring isn’t HTTP — Postgres, Redis, SMTP, an SSH bastion, a game server — point a TCP check at the host and port. WatchDeck opens a TCP socket and reports whether the connection succeeds within the timeout.

What you can configure

In the General section of the add-endpoint form, switch the type toggle to TCP port:

FieldNotes
HostHostname or IP. No protocol prefix.
PortInteger in 1–65535.
TimeoutConnect timeout. Default 10s. Configured under the Monitoring tab.

The Monitoring tab still owns interval, latency threshold, failure threshold, and recovery threshold — same defaults as HTTP. The SSL warning window field is hidden for port checks; see the section below.

Add a TCP / port check

What counts as healthy

The check runs net.Socket.connect(port, host) with setTimeout(timeout). Possible outcomes:

ResultStatusReason
Socket opened in timehealthy
Socket opened, but responseTime > latencyThresholddegradedLatency above threshold
Connection refused (ECONNREFUSED)down"Port connection refused"
Timeout / DNS failure / network errordownUnderlying socket error

What’s not configurable

Port checks are deliberately minimal:

  • No TLS handshake. WatchDeck does not negotiate TLS on port checks, so monitoring an HTTPS server’s certificate via port 443 won’t work — use an HTTP check on the URL and the SSL evaluator instead.
  • No protocol-level probe. WatchDeck only verifies that the port accepts a connection — it doesn’t speak Postgres, Redis, or SMTP. If the listener accepts the socket and immediately closes it, the check still reads as healthy.
  • No assertions. Body / header / JSON / SSL assertions don’t apply to a raw TCP socket. The Assertions panel and Test now preview are hidden for port checks.

If you need to verify “the database is actually responsive,” put a tiny health-check HTTP endpoint in front of it (e.g. an /health route on your app server) and monitor that with an HTTP check.

What’s next

Last updated on