Port & TCP monitoring
Check that a TCP port is open and responding.
What it watches
A port monitor opens a TCP connection to a host and a port, and that's the whole check. No HTTP, no rules: success is "the port accepted", and the time it took is the connect time.
Most of your infrastructure doesn't speak HTTP. A database, a mail server, a Redis, a game server, an SSH daemon — none of them will answer a GET, and all of them will tell you whether they're listening.
Latency here is connect time
On an HTTP check, latency is a sum with a story inside it. On a port check there's nothing to sum: no request is sent and no response is read, so the number is the TCP handshake and nothing else.
That makes it a clean signal. When connect time climbs on a port monitor, the network or the listener is the reason, because there is no third thing it could be.
Listening, not healthy
Be clear with yourself about what this proves. An accepted connection means a process is bound to that port and taking connections. It does not mean the database is answering queries, or that replication is caught up.
For anything that can be wrong while still accepting connections, put an HTTP or API check in front of it and let the port monitor answer the narrower question underneath.
Name a host and a port
The host is a bare hostname or a public IP, with no scheme and no path. The port is the number you'd connect to by hand.
curl -X POST https://upcheck-api-a.rekwiem.com/v1/monitors \
-H "Authorization: Bearer upk_your_key" \
-H "Content-Type: application/json" \
-d '{ "type": "port", "host": "db.example.com", "port": 5432 }'Tune it when the defaults aren't right
Highlighted is the default.
Build trust with
public status pages.
Every monitor can back a public status page, so the people asking whether you're down can answer it themselves. Ninety days of history per monitor, on your own domain.
Every outage,
written down as it happens.
A failed check opens an incident on its own, and it keeps a timeline: when it broke, what we saw, when it recovered. Nobody has to remember to write the post-mortem's first half.
Planned downtime
shouldn't page anyone.
Schedule a window and the checks keep running, but the alerts stay quiet and the uptime maths doesn't count it against you. One-off or recurring, per monitor.