UDP monitoring for DNS, NTP and other services that answer datagrams

UDP is silent by default

TCP has a handshake, so "connected" is a clear signal. UDP has nothing like it: a datagram goes out and, unless the service chooses to answer, nothing comes back. A monitor therefore has only one positive signal, a reply, and two ambiguous outcomes. Tenium's UDP monitor sends one probe datagram from the checker, waits for the timeout and classifies what happened. It is honest about what that can prove, and this page is equally honest about the services it cannot cover.

The three outcomes

Every UDP check ends in one of these states:

• A datagram comes back before the timeout: up. The response time is how long it took, and the size of the reply is saved in the details. The content is not inspected.
• The target host replies with an ICMP "port unreachable": the check fails immediately with "UDP port closed". This is the one negative signal UDP offers, and it arrives quickly.
• Nothing comes back before the timeout: failure after waiting. Silence is indistinguishable from a dropped packet, a firewall, or a service that ignores unknown input, so it is treated as down. The timeout you configure is capped at 15 seconds.

The probes: real DNS, real NTP, and a polite poke for the rest

Tenium chooses the payload by port. On 53 it sends a standard DNS query asking for the A record of example.com, so a working resolver or authoritative server replies; even a REFUSED answer counts as proof of life. On 123 it sends a 48-byte NTP client request, which any NTP server answers. On 161 it sends a short text string that is not a valid SNMP request, and on every other port a CRLF datagram. You cannot supply your own payload or check the reply against an expected string.

That is a real limit, and it decides where the monitor fits. It is excellent for the two protocols above and for any service that answers or rejects arbitrary input. It is a poor fit for protocols that demand a precise handshake before they will say a word.

Services that will look down even when healthy

Several well-known UDP services are designed not to answer strangers. WireGuard ignores any packet that is not a valid authenticated handshake, which is a security feature. OpenVPN configurations with TLS authentication drop unauthenticated packets the same way. Syslog receivers on port 514 only listen. Game servers usually expect their own query format: Source-engine games want a specific information request, Minecraft Bedrock a RakNet ping, voice servers their own protocol. SNMP agents drop packets that are not valid SNMP, and the generic probe is not. QUIC on 443 expects a proper initial packet.

Do not add these as UDP monitors and then wonder about the permanent red. Use the alternatives below.

Better options for silent services

The reliable pattern is to monitor from the inside out. For a WireGuard endpoint, run a small script on a client that checks the latest handshake time and calls a cron heartbeat URL only when the tunnel is healthy; if the ping stops, you are alerted. For a syslog collector, a minutely job that checks whether the log file has grown in the last five minutes and then calls a heartbeat catches a dead receiver. For game servers, many expose a TCP query or RCON port, a status web page or a plugin that reports player counts; use a port monitor or a keyword monitor on that. In all cases a ping monitor on the host covers the machine itself.

Firewalls, plans and testing

Allow inbound UDP from the addresses on the checker IP list on the port you monitor. Stateful firewalls handle the reply automatically. Private addresses are refused before any packet is sent. UDP monitoring starts on the Starter plan and counts as one monitor against your allowance of 100, 300 or 1000.

One quirk: the "test check" button in the editor is disabled for UDP monitors, so you save first and read the first result on the monitor page. If the first run says "No UDP reply", try the same probe from a shell to make sure the service answers at all: dig @your-resolver example.com A for port 53, or ntpdate -q host for port 123. If those work from outside your network, the monitor will too.