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 a second continent 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 and Singapore, and a failure is confirmed from a second continent 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.