UDP
Is your DNS, NTP, STUN or custom UDP service replying?
Sends a UDP datagram and waits for a sensible reply. UDP has no connection to establish, so unlike Port this has to speak a little of the protocol to know anything happened.
Use it when
You run a service that answers over UDP: a nameserver, an NTP server, a STUN/TURN server for video, or something of your own.
What to enter
| Field | Notes |
|---|---|
| Host and port | host:port, for example ns1.example.com:53. Not a URL. |
| Probe | DNS (default), NTP, STUN or Raw. |
| Payload | Raw only. Text, or hex: followed by hex bytes. |
| Expected reply | Raw only, optional. Text or hex:… that the reply must contain. |
The three named probes send a real request of that protocol and validate the shape of the answer. Raw sends exactly your bytes and, if you gave one, looks for your expected string in the reply.
Exactly when it's DOWN
- No valid reply after 3 attempts.
- An ICMP "port unreachable" comes back, which means nothing is listening.
- A reply arrives but does not match what the probe expects — for raw, your expected text is absent.
What it doesn't do
- UDP is unreliable by design, so a lost packet is indistinguishable from a dead service. That is why it retries three times; it is also why a low failure threshold produces false alarms here more than elsewhere.
- Many networks rate-limit or drop UDP from unfamiliar sources.
- Raw mode has no protocol knowledge: if you send bytes and expect nothing, any reply at all counts.
Example
ns1.example.com:53 with the DNS probe. For something custom: host collector.example.com:9000, probe Raw, payload hex:01ff, expected reply hex:02.
Alerts
Down, recovered, latency.
Last updated 4 October 2026
Still stuck?
If this did not answer your question, tell us and we will fix the page as well as answer you.