Port monitoring

Your database has no homepage.Watch its socket instead.

Port monitors open a TCP connection to a host and port, then pass when the handshake completes. For databases, mail servers and SSH it is the quickest honest signal you can get.

Port monitorsTCP
postgres-primary:5432PostgreSQL8 ms
cache-01:6379Redis3 ms
mail.example.com:25SMTPrefused
bastion:22SSH11 ms
mq-01:5672RabbitMQ6 ms
The quiet services

Built for services without an HTTP surface.

Postgres on 5432, Redis on 6379, SMTP on 25, SSH on 22. The services your product leans on hardest are the ones with no web page to check, so their outages usually announce themselves through application errors.

A port monitor watches the listener itself. When the socket stops accepting connections, the alert names the exact service instead of leaving you to work backwards from a stack trace.

  • Databases: PostgreSQL, MySQL, Redis, MongoDB
  • Mail infrastructure on SMTP
  • SSH, message queues and internal APIs
postgres-primary:5432TCP
Uptime / 7 days
99.94%
1 incident
Connect time
8 ms
avg this week
Checks
10,080
every 60 s
Last 40 checks
The handshake

A three-way handshake, then the truth.

Each check opens a TCP connection. If the handshake completes, the monitor is up and the connection closes immediately. Refused, unreachable or silent for 5 seconds counts as down, and alerts go out.

Nothing is sent into the service, no queries and no login attempts, which makes the check safe to point at production databases.

  • Success is a completed handshake
  • 5-second connection timeout
  • Connect time recorded on every check
Add port monitorTCP handshake
Host
postgres-primary.internal
Port
5432
Check interval
60 seconds
Handshake completed in 8 ms · connection closed
Routing

Alerts that reach the team that owns the socket.

Notification channels attach per monitor. The database team's Slack channel hears about 5432, the mail team's PagerDuty service hears about port 25, and nobody wakes up for a service they don't run.

12 native channels are available, from email to PagerDuty, each of them self-hosted along with the rest of your monitoring.

  • Channels picked per monitor
  • 12 native notification channels
postgres-primary
Owner: database team
Notify on status change
#db-oncall (Slack)
PagerDuty · database service
Email · dba@example.com
#general (Slack)
The whole team stays out of it
Who runs this

For the services that only fail loudly.

Teams running their own databases

Managed database prices sent you self-hosting, which made the socket your responsibility. A port monitor is the independent check that it is still accepting connections.

Anyone hosting email

When port 25 stops answering, mail queues silently instead of bouncing, then ages. A port check turns that quiet failure into an alert within a minute.

Platform teams with internal services

Queues, caches and internal APIs behind the VPN have no public health page. Your Checkmate instance sits on the same network, so it can watch all of them.

Scope

What it covers, and what it doesn't.

Covered

  • TCP connect to any host and port
  • Refused and unreachable connections detected
  • Timeouts after 5 seconds count as down
  • Connect time recorded per check
  • Internal services, since checks run from your instance
  • Alerts on 12 notification channels

Out of scope

  • Application health behind the socket: a database can accept connections while queries hang, pair with a deeper check where one exists
  • UDP services: the check is TCP only, though game server monitors cover many UDP game protocols natively
  • Credentials and queries: nothing is sent after the handshake, so logins and reads are never exercised
Under the hood

For the technically curious.

Handshake, then hang up

The check connects, confirms the handshake completed and closes the socket immediately. Total footprint on your service: one entry in the connection log.

A 5-second budget

A connection that cannot complete within 5 seconds is treated as down. That catches half-dead listeners that neither accept nor refuse, the failure mode that stalls applications worst.

Nothing sent to the service

No protocol payload, no auth attempts, no risk of tripping intrusion detection with malformed traffic. The check is indistinguishable from a client that connected and changed its mind.

Behind the firewall

Databases and queues should not be reachable from the internet, which rules out hosted monitors. Checkmate runs inside your network and watches sockets that stay private.

FAQ

Frequently askedquestions.

A port monitor opens a TCP connection to a host and port on a schedule. If the handshake completes the service is up, if the connection is refused or times out the monitor goes down and alerts fire.

Anything listening on TCP: PostgreSQL, MySQL, Redis, MongoDB, SMTP, SSH, message queues and internal APIs. If it accepts connections on a port, Checkmate can watch it.

No. The check completes the TCP handshake and closes the connection without sending a single byte of payload. It never authenticates and never runs queries, so it is safe against production systems.

Port monitors are TCP only. For game servers, which often run on UDP, Checkmate has dedicated game server monitors that speak more than 100 game protocols natively.

Yes. Checks run from your self-hosted instance, so any socket your instance can route to can be monitored, including services that are deliberately unreachable from the internet.

Checkmate is one. It is open source under AGPL-3.0, self-hosted, with unlimited monitors and no per-check pricing.

Get started

Every feature,no paywall.

Checkmate is open source under AGPL-3.0. Self-host it and this feature ships free, on your servers, with your data.