← All features

Probe type · Starter+

TCP / port probe

What telnet and netcat do, on a schedule. Opens host:port, optionally wraps in TLS, optionally reads the server banner, reports state on connect time + banner contents.

Why you need it

A TCP probe is the right tool for any TCP-based protocol that isn't HTTP. On every run the probe:

  1. Resolves the hostname and applies the SSRF guard — private and link-local IPs are rejected before any packets fly.
  2. Opens a TCP connection to the target IP and port. The connect time is the latency metric. Default Degraded threshold is 1000 ms.
  3. Optionally wraps in TLS — when Use TLS is on, the probe runs an implicit-TLS handshake from byte zero. Covers SMTPS (465), IMAPS (993), LDAPS (636). STARTTLS protocols are not covered.
  4. Optionally reads the banner — when a Banner contains substring is configured, reads up to 256 bytes and asserts the substring appears. Catches the "port is listening but the daemon isn't the right service" case.
  5. Closes cleanly. No commands sent — pure connect-and-banner. Stateless, replay-safe.

The probe flips Down on connection refused, connect timeout, DNS failure, TLS handshake failure, or banner-assertion failure. It flips Degraded when connect time exceeds the threshold. The last successful banner is stored on the monitor for comparison without running tcpdump.

Where it pays off

Use a TCP probe when the service speaks a TCP-based protocol that isn't HTTP, and you want connectivity or connectivity-plus-banner-assertion. Concrete cases:

  • SMTP servers on 25 / 465 / 587. Assert 220 ESMTP on the banner.
  • SSH bastions on port 22 with SSH-2.0 as the expected banner.
  • TLS-only ports — IMAPS 993, LDAPS 636, SMTPS 465 — with Use TLS on so the probe catches a broken TLS configuration.
  • Custom internal protocols — anything you wrote that listens on a TCP port and emits a startup line.
  • Database ports for connectivity-only. For a real auth + query assertion use the Database probe.

Not the right choice when: the service speaks HTTP (use HTTP). For STARTTLS protocols use the Email probe (TCP's TLS flag does implicit-TLS only). For certificate expiry detail use the SSL probe. For internal-network services blocked by the SSRF guard, use the Heartbeat probe.

Configuration parameters

Field Type Required Default Description
Name string Required Human-readable label shown in the dashboard, on the status page, and in alert subject lines.
Target string (host:port) Required Hostname or IP plus port, e.g. mail.example.com:25. Internal / RFC1918 / link-local hosts rejected by the SSRF guard.
Use TLS boolean Optional false When on, wraps the socket in an implicit-TLS handshake from byte zero. Required for SMTPS 465, IMAPS 993, LDAPS 636. STARTTLS is NOT covered.
Banner contains string Optional Substring asserted against the first ~256 bytes the server sends. Null = connectivity-only. Examples: "220 ESMTP", "SSH-2.0", "+PONG".
Connect Degraded (ms) integer Optional 1000 Connect time (plus TLS handshake when applicable) above which the probe flips Degraded. Zero disables the latency tier.
Interval (seconds) integer Optional 60 Time between checks. Floor: 30 s on Starter+.
Timeout (seconds) integer (1-120) Optional 30 Hard ceiling for connect + TLS + banner read.
Show on status page boolean Optional false on create Master visibility gate for the public page.
Paused boolean Optional false Master kill-switch.
Auto-email alerts boolean Optional true Per-probe switch on top of per-watcher toggles.
SLA target decimal (99.0-99.999) Optional Optional uptime SLO.

Available on Starter+. Already on StatusPulse? See the full config in Help →

Related

Try TCP / port probe in StatusPulse

5 probes, 1 status page, forever. No credit card. US or EU host — you choose.