Documentation

A TCP monitor opens a connection to a host and port and reports whether the far end accepted it. A UDP monitor sends a datagram to a host and port and reports whether anything came back. Both answer the same question — is this port answering — but they answer it with very different confidence, and the second half of this page is mostly about that difference.

What It Is For

What It Is Not For

A port check tells you the door opens. It does not tell you what is behind it:

Why TCP and UDP Are Not the Same Check

TCP has a handshake. When the monitor connects, the far end either completes that handshake or it does not, and every outcome means something specific. An accepted connection proves a process is listening and accepting work. A refusal proves the host is up and nothing is listening on that port. Both are real answers.

UDP has no handshake. Sending a datagram is a local operation — the packet leaves, and the network is under no obligation to tell you what happened to it. So a UDP monitor cannot learn anything by sending alone. It has to send something the service will answer, and then wait for the answer. The reply is the entire proof.

That is why UDP checks need a payload that suits the service. Sending random bytes to a port makes most services ignore you, and being ignored looks exactly like being down.

What a TCP Check Does

1. Opens a connection to the host and port.
2. Records the time the connection took as the response time.
3. Optionally reads the banner — the greeting many services send as soon as you connect, such as an SSH or SMTP version line.
4. Closes the connection. The monitor never sends anything to the service — even a banner read only listens.

If you turn banner reading on, the monitor reads up to 1024 bytes, decodes them as text, and stores the result with the check. It waits at most 5 seconds for the banner, less when little of the monitor’s timeout is left — but always at least one second.

The banner is informational until you give it an expected keyword. With a keyword set, the check passes only if the keyword appears somewhere in the banner text, matched exactly, upper and lower case included. A missing banner, an empty one, a failed read or a keyword that is not there all turn the check red. Without a keyword, a banner that cannot be read does not fail anything — the check still passes on the connection alone and the banner is simply absent.

What a UDP Check Does

1. Resolves the hostname. This has its own limit of 5 seconds, or the monitor’s timeout if that is shorter.
2. Sends one datagram containing the payload.
3. Waits for a reply until the timeout, unless you turned waiting off.
4. Optionally compares the reply against an expected string, then records how many bytes came back.

If you do not set a payload, the monitor picks one by port:

For anything that is not DNS or NTP, plan on writing the payload yourself. The service decides what deserves an answer, and the default placeholder usually does not.

A UDP monitor needs an explicit port in its address. There is no assumed default: an address with no port fails the check immediately with a message saying so, because guessing a port would silently monitor the wrong thing.

Turning the Reply Requirement Off

UDP has a fire-and-forget mode: send the datagram and call the check successful as soon as it leaves the socket. Be clear about what that buys you. It proves the hostname resolved and the packet was handed to the network. It proves nothing whatsoever about the service at the other end, which may have been switched off for a month. A monitor in this mode will essentially never go down, so treat it as a send test, not availability monitoring.

What Silence Means

A timeout is the one result that reads differently on each protocol, and it is worth knowing which kind of silence you are looking at.

On TCP, silence is unusual. A host that is up and has nothing on the port normally refuses the connection at once, and the monitor records that refusal. Silence instead of a refusal usually means a firewall is dropping the packets rather than rejecting them, or the host itself is gone.

On UDP, silence is the normal way to be ignored. No reply can mean the service is down, or that a firewall dropped the request, or that the reply was dropped on the way back, or simply that the service did not consider your payload worth answering. The monitor cannot tell these apart, so a UDP monitor that times out is telling you “no answer”, not “the service is down”. Sometimes the operating system does receive an ICMP port-unreachable message, and then the check fails with that error instead of a timeout — but whether that message arrives is up to the network in between.

This is the practical consequence: a UDP monitor is only as trustworthy as the payload you send. Get the payload right and it is a genuine check. Get it wrong and it reports a permanent outage on a healthy service.

Status Logic

Neither monitor has a degraded state. There are no response-time thresholds on TCP or UDP — the result is up, down or timed out.

Down and timeout both count as downtime and both open an incident — after the confirmation threshold, three consecutive failing checks by default, so one dropped packet does not page anyone.

Configuration

The TCP form has an Expected Response box: fill it in and the check reads the banner and requires that text in it; leave it empty and the check only proves the port accepts connections. The UDP payload and its expected response are still not in the form — set those through the REST API or the MCP tools, on the same monitor you created in the interface.

Key Features

• One monitor type for any TCP or UDP port, with no agent on the target
• TCP records the connection time and, on request, the server banner
• Optional banner keyword on TCP and expected reply text on UDP, both turning a mismatch into a failure
• Sensible UDP payloads for DNS and NTP built in, and a custom payload for everything else
• A refusal, a timeout and an unreachable port are recorded as different errors, so the monitor page says what actually happened