UDP port monitoring for services that fail quietly

DNS, NTP, SNMP, VoIP, RADIUS, VPN tunnels and most game servers run over UDP – and UDP services have a habit of failing silently. There is no connection to refuse and no handshake to time out, so a dead DNS resolver or NTP server can go unnoticed while every website and TCP check stays green. This guide explains how UDP monitoring works despite UDP being connectionless, why custom payloads, packet loss thresholds and response keywords matter, what people typically monitor over UDP and how to set up reliable checks.

What is UDP monitoring?

UDP monitoring is a type of uptime monitoring that checks whether a service running over the User Datagram Protocol is responding. A monitor sends packets to a target host and UDP port, waits for a reply within a configured timeout, evaluates how many packets went unanswered and, ideally, checks that the reply contains the data it should. If the service stops answering or loses too many packets, the monitor raises an incident and notifies you.

UDP matters because a large part of the infrastructure that everything else depends on uses it: DNS resolution, time synchronisation with NTP, network management with SNMP, voice over IP with SIP and RTP, authentication with RADIUS, log shipping with syslog, NAT traversal with STUN and TURN, modern VPNs such as WireGuard and most multiplayer game servers. When one of these fails, the symptoms show up elsewhere – websites that do not load, logins that fail, calls that drop – and the cause is easy to miss.

Why UDP is harder to monitor than TCP

TCP is connection-oriented: before any data flows, client and server complete a three-way handshake, so a TCP monitor knows immediately whether a service is listening. UDP has nothing like that. A client simply sends a datagram and hopes for an answer. If nothing comes back, there is no way to tell from that alone whether the service is down, the packet was lost, a firewall dropped it or the service received it but chose to ignore it.

Two consequences follow. First, a UDP check is only meaningful when it sends a request the service actually answers – an empty or random packet usually gets no reply even from a perfectly healthy server. Second, some packet loss is normal on UDP, so a single missing reply should not count as an outage. That is why UDP monitoring relies on three tools TCP checks do not need: custom payloads, packet loss thresholds and response validation. A closed port sometimes triggers an ICMP “port unreachable” message, which can help, but many firewalls suppress it, so you cannot rely on it.

Monitor UDP services on any port

In principle you can point a UDP monitor at any host and port, as long as the service behind it returns a response. In practice, the well-known UDP services are the ones worth watching first, because so much depends on them. The table lists common ports and the kind of request that produces a reply.

Send a custom payload

Many UDP services only answer when they are asked correctly. A DNS server ignores a packet that is not a valid DNS query, an NTP server ignores anything that is not an NTP request and a game server only replies to its specific query format. A UDP monitor should therefore let you define the packet body, either as plain text for text-based protocols such as SIP or as hex bytes for binary protocols such as DNS, NTP or game queries.

The best payload is the smallest real request the service supports: a DNS query for a record you control, a standard NTP client packet, a SIP OPTIONS ping or the game’s official status query. Avoid payloads that change state or trigger rate limits, and keep credentials such as SNMP communities or RADIUS secrets dedicated to monitoring with read-only rights.

Define your packet loss threshold

Because UDP gives no delivery guarantee, a healthy service on a busy network still loses the odd packet. A monitor that sends several packets per check and calculates the share without reply can distinguish normal loss from a real problem. Set the threshold to what the service tolerates: for DNS a few lost packets are absorbed by client retries, while VoIP quality drops noticeably above a few percent loss and calls become unusable well before the service is fully down.

Thresholds turn UDP monitoring from a pure up-or-down check into a quality check. You get alerted when a service degrades – calls get choppy, games lag, lookups slow down – not only when it disappears completely. Combine the loss threshold with response time tracking, and alert when replies arrive much slower than the usual baseline.

Validate the response with a keyword

A reply does not guarantee health. A DNS server may answer with SERVFAIL or a wrong address, a misconfigured service may return an error message, and a device on the wrong IP may respond with something entirely different. Checking the response for a required keyword or byte sequence – the expected IP address in a DNS answer, a known server name in a status reply, a specific header in a SIP response – confirms the service returns correct data, not just any data.

$ dig @203.0.113.53 example.com A +time=3 +tries=1
;; ANSWER SECTION: example.com. 300 IN A 93.184.215.14
$ ntpdate -q time.example.net
server 203.0.113.123, stratum 2, offset +0.0021, delay 0.0184
$ snmpget -v2c -c public 203.0.113.1 sysUpTime.0
Timeout: No Response from 203.0.113.1

On the command line, protocol-aware tools do this naturally: dig shows the answer section of a DNS response, ntpdate -q or chronyc show offset and stratum, snmpget prints the requested value and nc -u can send a raw payload for simple text protocols. A monitor automates the same check and records the result every time.

Set up UDP monitoring in a few steps

Hosted uptime services that support UDP, and open-source tools such as Nagios plugins (check_dns, check_ntp, check_snmp, check_udp), Zabbix, Icinga or Prometheus with the blackbox exporter’s DNS module, all follow roughly the same setup. Test every check manually first, from outside the network, so you know a healthy service really answers the payload you configured.

• Add the host or IP address – no protocol prefix – and the UDP port of the service
• Define the payload to send, as text or hex, using a real protocol request
• Set the timeout, the number of packets per check and the acceptable packet loss
• Add a keyword or byte pattern the response must contain
• Allow the monitoring IPs through firewalls and NAT rules for that port
• Require confirmation retries, and if possible a second region, before alerting
• Choose notification channels and save

Benefits of UDP monitoring

The first benefit is seeing what TCP checks cannot. A DNS server can stop returning the expected answer while your website monitor is still green, because browsers and the monitor may use different resolvers or cached results. A dedicated UDP check catches that immediately. The second benefit is catching degraded service before a full outage: with packet loss thresholds and response times, you notice the network problems behind dropped calls, game lag and slow lookups while the service still technically responds.

The third benefit is confirming that the response is actually correct. Keyword validation means you monitor behaviour, not just activity, and a service that answers with errors is treated as the failure it is. Together with confirmation retries and checks from several regions, that keeps alerts both early and trustworthy.

What people monitor over UDP

One monitoring approach covers a home server in the basement and a corporate VPN gateway. In hobby setups and home labs, typical targets are game servers such as Minecraft, Valheim or Counter-Strike 2 – check that the server answers before your players tell you it does not – and DNS resolvers such as Pi-hole or AdGuard Home, where a failure makes everything at home look broken. Media servers such as Plex and Jellyfin use UDP discovery services, and self-hosted voice chat such as Mumble is best watched on the voice port itself, not just the machine it runs on.

In small businesses and teams, the list usually includes VPN gateways (WireGuard, OpenVPN), VoIP infrastructure with SIP and RTP, internal and authoritative DNS servers, RADIUS authentication servers, NTP servers, SNMP endpoints on network devices, syslog collectors and STUN/TURN servers that keep WebRTC calls working behind NAT. Note that WireGuard deliberately does not answer unauthenticated packets, so it is usually monitored indirectly – for example by checking a host or service reachable only through the tunnel, or a TCP or ICMP check on the gateway.

• DNS: alert when lookups fail or return the wrong address
• NTP: catch time drift before it breaks logs, certificates and authentication
• RADIUS: know when logins stop working at the authentication layer
• SNMP: confirm the devices your dashboards depend on still respond
• Syslog: detect when log delivery stops instead of finding a silent gap later
• SIP and RTP: spot the packet loss behind dropped calls and choppy audio

Common UDP monitoring mistakes

The most common mistake is sending an empty or meaningless packet and treating “no reply” as down – or worse, treating “no ICMP error” as up. Without a proper payload a UDP check proves nothing. The second mistake is alerting on a single lost packet, which on UDP produces a steady trickle of false alarms. The third is skipping response validation, so a DNS server that answers every query with SERVFAIL looks healthy.

Also watch for firewalls and NAT that pass the monitoring traffic but block real clients, or the other way round, rate limits on DNS and NTP servers that treat frequent monitoring as abuse, and services that do not reply by design, such as syslog receivers. For those, monitor the result – logs arriving at the collector – rather than the port.

Website monitoring with monitordefend

monitordefend does not offer UDP, TCP, port or ping monitoring, so it cannot check DNS servers, NTP, VoIP or game servers directly. It is a hosted website monitor: every five minutes from Germany it requests your homepage over HTTP, confirms a failure with a second attempt, records the response time and sends email alerts, and it also crawls for broken links, checks sitemaps, Google indexing, checkout pages and suspicious changes to your site. For a one-off look at your domain’s DNS records, the free DNS checker helps.

Frequently asked questions

What is UDP monitoring?

A type of uptime monitoring that checks whether a service running over UDP responds. Because UDP has no handshake, the monitor sends packets to a host and port, waits for replies within a timeout, evaluates packet loss against a threshold and optionally checks the reply for an expected keyword.

Why use UDP monitoring?

Many essential services use UDP rather than TCP: DNS, NTP, SNMP, SIP, RADIUS and many game servers. HTTP and TCP port checks cannot test them, so without UDP monitoring they fail quietly until users report failed lookups, dropped calls or lag.

How does UDP monitoring work?

Each check sends one or more UDP packets with a payload the service understands. The monitor evaluates whether replies arrive in time, whether packet loss stays below the threshold and whether the response contains the expected data, and it confirms failures with retries before alerting.

What is the difference between UDP monitoring and TCP port monitoring?

TCP port monitoring checks whether a connection opens on a port, which the handshake proves. UDP has no handshake, so UDP monitoring sends a request and checks the reply, packet loss and response content. That suits DNS, SNMP, NTP, SIP, RADIUS and game servers.

Can I monitor a UDP port without a payload?

Rarely. Most UDP services ignore packets that are not valid requests, so an empty packet gets no reply even from a healthy service. Use a real protocol request such as a DNS query or NTP time request.

What packet loss threshold should I use?

It depends on the service. DNS tolerates occasional loss thanks to client retries, while VoIP degrades above a few percent. Start with a threshold that matches what users notice and adjust it after watching the normal baseline for a while.

Does monitordefend support UDP monitoring?

No. monitordefend monitors websites over HTTP every five minutes from Germany and alerts by email; it has no UDP, TCP or ping checks.

Related pages

• TCP monitoring: keep every service on your server reachable
• Port monitoring: watch any port on your server
• Ping monitoring: check that any server or device is reachable
• DNS monitoring: protect your website from DNS changes and outages
• DNS checker
• The All-in-One Website Monitoring Tool