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.
TCP checks · last run
connect time
How it works
One TCP handshake per check, 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
Consensus rule: an incident opens only when a majority of regions fail, so 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
3s
Connect timeout, fast enough to catch real failures
60s
Default check interval from every region, with faster intervals on higher plans
4
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.
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, so a 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.
Start monitoring your TCP services
Port monitoring for databases, mail servers, SSH and any custom TCP service, with multi-region consensus to silence the noise.
No card for the free plan · 14-day trial on paid plans · Cancel anytime