New: Connect AI assistants via MCP

Core Concepts

Port Monitoring

Port Monitoring (TCP)

Port monitoring opens a TCP connection to a host on a specific port and reports whether the service is accepting connections. It's the right check type for any service that listens on a TCP port other than 80/443 — database engines, mail servers, SSH, custom application protocols, and anything else where "is the service running and reachable?" is the question that matters.

Use Cases

  • Database engines — Postgres on 5432, MySQL on 3306, SQL Server on 1433, MongoDB on 27017
  • Mail servers — SMTP on 25/587, IMAP on 143/993, POP3 on 110/995
  • SSH — port 22 reachability for bastion hosts and managed servers
  • Cache and broker services — Redis on 6379, Memcached on 11211, RabbitMQ on 5672
  • Custom TCP services — any application protocol that binds to a port, including non-HTTP gRPC backends, game servers, and bespoke daemons

How It Works

Every check interval, from every monitored region, the system:

  1. Attempts a TCP connection to host:port with a 3-second connect timeout
  2. Measures the time-to-connect in milliseconds (DNS lookup + TCP three-way handshake)
  3. Reports success if the handshake completes; otherwise records the failure reason (connection refused, timed out, DNS failure, network unreachable)
  4. Persists the result so the multi-region consensus engine can decide whether to alert

Port monitoring does not send any payload after the connection is established. It checks that the socket can be opened — not that the service inside speaks the right protocol. For HTTPS endpoints use an HTTP monitor with SSL sub-check; for SMTP or other application-layer health checks, use a dedicated tool.

Setting Up Port Monitoring

  1. Click Add Monitor and select Port (TCP) as the monitor type
  2. Enter the hostname or IP in the Host field, and the port number (1–65535) in the Port field
  3. Pick the regions you want the connection attempted from
  4. Save the monitor — the first check runs immediately

Port is a top-level monitor type. One monitor checks one port; if you need to monitor multiple ports on the same host (e.g. SMTP and IMAP on a mail server) create one Port monitor per port.

Multi-Region Consensus

Network paths to a service can fail regionally without the service itself being down. Port monitoring uses the same multi-region consensus rule as the HTTP and Ping check types:

  • An incident is opened only when a majority of monitored regions report failure (66% threshold for 5+ regions, 3 of 4, 2 of 3)
  • If any region still reports success, no incident is opened
  • An incident is closed only when every monitored region is connecting successfully again

Common Failure Reasons

The error message recorded with each failed check is one of:

  • Connection refused — the host is up but nothing is listening on that port (service crashed, bound to a different interface, or the wrong port)
  • Connection timed out — packets are being dropped somewhere on the path (firewall, security group, or host is unreachable)
  • DNS resolution failed — the hostname doesn't resolve to an address
  • Network unreachable — no route to host (regional outage, routing misconfiguration)

First Steps When a Port Monitor Fails

  1. SSH to the host and confirm the service is running (systemctl status / docker ps)
  2. Check it's bound to 0.0.0.0 or the public interface, not just 127.0.0.1
  3. Verify your firewall / security group allows inbound TCP on that port from public addresses
  4. Try a manual nc -zv {host} {port} from a known-good network
  5. Confirm the port number on the monitor matches the service's actual listening port

Notifications

Port failures are treated as critical-tier incidents. The notification subject reads "TCP Port Unreachable", includes the host and port, the regional context, and the failure reason. Recovery notifications fire when every monitored region is connecting successfully again ("TCP Port Reachable Again") and the incident closes automatically.

Limitations

  • Private addresses are blocked — we won't connect to RFC1918, loopback, or other non-public addresses. Self-host a probe if you need to monitor internal infrastructure
  • No application-layer check — a successful TCP connect doesn't prove the service inside is healthy. Use an HTTP monitor for HTTP services and a heartbeat for background jobs
  • No TLS handshake — Port monitors don't validate certificates. For HTTPS endpoints use an HTTP monitor with the SSL sub-check
  • Plan-gated — Port monitoring is available on the Basic plan and above
Ping MonitoringHeartbeat Monitoring