TCP monitoring

Port monitoring for the things that don't speak HTTP

Databases, caches, mail servers, message queues, game servers. A TCP monitor opens a connection to host and port on a schedule and tells you when it stops being accepted.

Free for one monitor. No card needed.

db.tidepool.io:5432Port open41 ms
Status BeeStatus Bee probeYour serverdb.tidepool.io:5432SYNSYN-ACKACK
  • Postgres:5432
  • Redis:6379
  • SMTP:587
  • SSH:22
  • RabbitMQ:5672
  • Game server:27015
30s
Fastest interval
Any
Port, 1 to 65535
10s
Connect timeout
IPv6
Supported

What a TCP check actually does

A TCP monitor completes the three-way handshake with your server: it sends SYN, waits for SYN-ACK, replies with ACK, and hangs up. If the handshake completes, the port is open and something is listening. If the connection is refused or times out, it is not. The time between the first packet and the last is the latency you see.

That makes it the right check for anything that is not a web page. Your app might still return 200 while its database is unreachable; a TCP monitor on port 5432 catches that a minute earlier, before the errors pile up in front of customers.

Anything with a port

Type host:port and pick an interval. Hostnames and IP addresses both work, IPv6 in brackets. Each monitor has its own timeout, and a refused connection is reported differently from a silent timeout so you know which one you are dealing with.

  • Postgres 5432, MySQL 3306, Redis 6379, RabbitMQ 5672, SMTP 25 or 587, SSH 22
  • Custom ports for game servers, VPN endpoints and internal tools you expose
  • Private addresses are refused, so a monitor can never scan your own network
Monitors3 up · 1 degraded
  • db.tidepool.io:5432
    TCP · every 1 min
    41 ms
  • cache.tidepool.io:6379
    TCP · every 1 min
    8 ms
  • mail.tidepool.io:587
    TCP · every 5 min
    63 ms
  • mq.tidepool.io:5672
    TCP · every 1 min
    1 204 ms

When the port stops answering

Set how many failures in a row count as down. Then link the monitor to a status page component and decide what should happen: a status change, a drafted incident, or a published one with subscribers notified.

  • A slow handshake shows up as rising latency before it becomes a failure
  • Recovery needs the same number of consecutive passes, so a flapping port does not spam anyone
  • Every result is kept for 30 days, with daily rollups beyond that
db.tidepool.io:5432Outage · 7 min
  1. 04:02:10

    Connection to db.tidepool.io:5432 timed out after 10 s

  2. 04:03:10

    Timed out again. Threshold reached.

  3. 04:03:11

    Component “Database” set to Outage; incident drafted for review

  4. 04:03:12

    Slack #ops and the on-call webhook notified

  5. 04:09:40

    Connected in 38 ms, twice in a row

  6. 04:09:41

    Component back to Operational

Setting one up

01

Enter host and port

db.example.com:5432, or [2001:db8::1]:443 for IPv6. No scheme, no path.

02

Choose interval and timeout

Every minute is a good default for a database. Timeouts default to 10 seconds.

03

Link a component

Point the monitor at the component your customers would recognise, such as “Database”, and pick the rule.

The other checks

TCP monitoring questions

Watch the port your app depends on.

One monitor and a status page, free. No card needed.

Add a TCP monitor