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.
Watch 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
Pass on a completed TCP handshake.
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
Alert 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.
13 native channels are available, from email to PagerDuty, each of them self-hosted along with the rest of your monitoring.
- Channels picked per monitor
- 13 native notification channels
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.
See 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 13 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
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.
Frequently asked questions
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.
