Port Monitoring

TCP Port Monitoring

Verify databases, mail servers, SSH, message brokers and any custom TCP service is accepting connections. From every monitored region, with the exact failure reason tagged on every incident so you know which layer broke.

Start Free Trial → View Pricing

How It Works

One TCP handshake every minute, from every region

Each monitored region attempts a TCP connection to host:port with a three-second connect timeout. We measure how long the handshake takes (DNS lookup plus the three-way handshake) and report success if the socket opens. No payload is sent after the connection — the check answers "is the service accepting connections?" and nothing else.

When a connection fails, the cause is categorized and surfaced as the incident root cause: refused, timed out, DNS error, or network unreachable. Triage takes seconds instead of grepping logs.

3-second connect timeout, fast failure detection
Categorized failure reason on every incident
Multi-region consensus alerting, same as HTTP

db.example.com:5432All regions online

🇺🇸 Ashburn

connected in 11 ms

🇺🇸 Portland

connected in 71 ms

🇩🇪 Nuremberg

connected in 103 ms

🇸🇬 Singapore

connection timed out

Consensus rule: incident opens only when a majority of regions fail — a single regional issue doesn't trigger an alert.

Features

Service-level checks for every TCP port

Any TCP Service

Postgres on 5432, MySQL on 3306, SMTP on 25, SSH on 22, Redis on 6379, RabbitMQ on 5672 — anything that listens on a TCP port. One monitor per port, with all the regional and alerting machinery the rest of Sentinel gives you.

Real Failure Reasons

Every failed check is tagged with the actual reason — connection refused, connection timed out, DNS resolution failed, or network unreachable. The incident root cause tells you exactly which layer broke without having to dig through logs.

Multi-Region Consensus

TCP connections from every monitored region. Incidents open only when a majority of regions confirm the failure and close only when every region reconnects. Routing or peering issues in a single region don't trigger false alarms.

What Can You Monitor

Every TCP service your stack depends on

If it accepts TCP connections on a known port, Sentinel can verify it from every region you choose. Here are the most common services teams point port monitors at.

1-65535

Any TCP port the service binds to

Connect timeout — fast enough to catch real failures

every 60s

Default check interval, from every region

Failure categories surfaced as root cause

Databases

Postgres on 5432, MySQL on 3306, SQL Server on 1433, MongoDB on 27017, Redis on 6379. Confirm your data layer is accepting connections without exposing the actual database credentials to the monitoring service.

Mail Servers

SMTP on 25 and 587, SMTPS on 465, IMAP on 143 and 993, POP3 on 110 and 995. Every port a mail server uses can be monitored independently so the right team gets paged when the right service goes down.

SSH, Brokers, Custom

SSH on 22 for bastion hosts, RabbitMQ on 5672, Kafka on 9092, gRPC backends on any port, and any bespoke TCP service. If it binds to a port, you can monitor it from every region with a single click.

FAQ

Port monitoring questions

How is port monitoring different from HTTP monitoring?

HTTP monitoring opens a connection AND sends a request, expecting a status code and optionally a body. Port monitoring opens the connection and stops there — it verifies the TCP socket is reachable and a service is listening, without speaking the protocol that runs on top. Use HTTP for web endpoints; use port for everything else that listens on a port.

Does port monitoring detect application-layer failures?

No. A successful TCP handshake proves the service accepted the connection, not that the process inside is healthy. A wedged database that's still accepting connections will pass a port check while failing its actual queries. Combine port monitoring with an application-layer health check where possible — for HTTP services use an HTTP monitor, for databases consider a custom health endpoint.

What kinds of failures will I see?

Every failed check is tagged with one of four reasons: 'Connection refused' (host is up but nothing is listening), 'Connection timed out' (packets dropped on the path — firewall, security group, or unreachable host), 'DNS resolution failed' (the hostname doesn't resolve), and 'Network unreachable' (no route to host). The incident root cause shows exactly which one fired.

Can I monitor multiple ports on the same host?

Yes — create one Port monitor per port. A mail server might have one monitor for SMTP on 25, another for IMAP on 993, and another for SMTPS on 465. Each runs independently and creates its own incidents when it fails, so a port-level outage doesn't get conflated with a host-level outage.

Does this work for internal services on private IPs?

Public hosts only by default. Private addresses (RFC1918 ranges, loopback, link-local) are refused so Sentinel can't be used as a port scanner against private networks. For internal monitoring, the same monitor type can be run from a self-hosted Sentinel probe inside your network.

Is port monitoring on the free plan?

Port monitoring is available on the Basic plan and above, alongside DNS, ping, and domain expiration monitoring. The free plan covers HTTP/HTTPS uptime and JSON response assertions.

Every TCP service, every region

Start monitoring your TCP services

Port monitoring for databases, mail servers, SSH and any custom TCP service. Multi-region consensus to silence the noise. 14-day free trial on paid plans, cancel anytime.

Start Free Trial → View Pricing