TCP port
TCP port monitoring
Any host, any port, and what it says when it answers.
Try it now
One check, from one place, right now, and nothing is saved. A monitor checks from every location we run and confirms a failure from three continents before anybody is woken, which a single look cannot show you.
What it is for
The check for a service that is not a website. A database, a game server, a VPN endpoint, SSH: things that listen on a port and have no HTTP to ask and no page to read.
We open the port, and the check can also require the greeting the service should give. A port that accepts a connection and then says nothing is what a half-dead service looks like from outside, and a plain open port check calls that healthy.
Like every check here, it runs from Amsterdam, New York, Sydney and Singapore, and a failure is confirmed from three continents before anybody is woken. How that works.
What you can set
Everything below is on the form when you add one, on every plan.
- Host and port
- A hostname or address and a port, because there is no sensible default port to guess.
- Expected greeting
- A regular expression the first thing the service says has to match.
Questions
Which ports are worth watching with a TCP check?
Port 22 for SSH, 3306 for MySQL, 5432 for PostgreSQL, 6379 for Redis, and whatever else your service listens on. There is no default port to fall back on, because a guessed port is a monitor watching something you did not ask about, so the port is part of what you type.
What does the expected greeting do?
It reads the first bytes the service sends and matches them against a regular expression you give, which is what a banner grab is. Without it this is a plain open port check, and an open port check calls a half-open service healthy: the port accepts your connection and then the thing behind it never says a word.
Connection refused, or a timeout?
Refused means the host answered and told you nothing is listening there, which is usually a service that stopped rather than a machine that went. A timeout means nothing came back at all, which is a firewall dropping packets, a host unreachable, or a network in between. They are reported apart for that reason.
Can you check a UDP port?
No, and we say so rather than offering something that looks like it. A UDP port that is open and a UDP port that is filtered are indistinguishable from outside unless the service chooses to answer, so a UDP port check is a guess wearing a status pill. Watch the service some other way.
Why not netcat the port from a script?
For a port on a host you already have a machine next to, that is a perfectly good check and takes one line. The gap is the same as everywhere else here: the script runs somewhere, and that somewhere is a thing that fails without telling you. A connection that fails from one place also does not distinguish a service that has stopped from a route that has broken, which is what three continents settle before anybody is called.