Overview
UDP (User Datagram Protocol) monitoring allows you to monitor the availability and responsiveness of UDP-based services. It is available on the Solo, Team, and Enterprise plans.
HTTP and TCP port checks have a blind spot: they can't reach services that communicate over UDP. VPNs, VoIP systems, game servers, and DNS resolvers all depend on UDP, and a green status on an HTTP monitor won't help you when remote workers can't connect or calls start dropping. UDP monitoring closes that gap by testing the UDP service itself, giving you visibility where traditional checks fall short.
How It Works
A UDP monitor sends multiple UDP packets (5–20, depending on the configured packet loss threshold) to a specified host and port at a configured interval and evaluates the result based on:
Timeout — whether the target responds within the configured timeout window.
Packet loss threshold — whether the percentage of lost packets exceeds a user-defined limit.
Expected response keyword (optional) — whether the response from the target contains an expected string (only evaluated if packet loss is within the threshold).
If any of these conditions are not met, the check is considered failed.
Configuration
Required Settings
Setting | Description |
Friendly name of monitor | A friendly display name for the monitor |
URL, IP or host to monitor | The hostname or IP address of the target (no protocol prefix needed, e.g. |
Port | The UDP port number to monitor |
Optional Settings
Setting | Description |
Send to port | A custom text or hex to send as the body of the UDP packet |
Packet Loss Threshold | The maximum acceptable packet loss percentage before the monitor is marked as Down |
Keyword to look for | An expected string that must appear in the UDP response for the check to be considered successful |
Regional Monitoring
UDP monitors support regional monitoring. You can select monitoring regions (North America, Europe, Asia, Oceania) to detect geographically localized outages -- for example, when a service is down in one region but still reachable from another.
Packet Loss Threshold
The packet loss threshold is a key setting for UDP monitors. Because UDP is a connectionless protocol with no guaranteed delivery, some degree of packet loss is normal. The threshold lets you define how much packet loss is acceptable before the monitor is considered down.
During each check, the monitor sends multiple UDP packets to the target and measures how many are lost (i.e. no response received). The percentage of lost packets is then compared against your configured threshold.
If the measured packet loss is at or below the threshold, the monitor remains Up.
If the measured packet loss exceeds the threshold, the check is considered failed.
Data to send to port
The payload is an optional string or hex sent as the body of the UDP packet. This is useful for services that require a specific request format to respond. For example:
DNS servers may need a properly formatted DNS query.
Game servers often respond to specific ping/status packets.
SIP/VoIP services may expect an OPTIONS or REGISTER request.
Keyword Matching
You can optionally set an expected keyword to verify that the UDP response contains a specific string. This goes beyond simple availability checking and validates that the service is returning correct data.
Use cases:
Verifying that a DNS server returns the expected record.
Confirming that a game server responds with a valid status message.
Detecting degraded services that respond but with incorrect or unexpected data.
If a keyword is set, the check is only considered successful when both the packet loss is within the threshold and the response contains the expected keyword.
Monitor States
UDP monitors report the following states:
State | Description |
Paused | Monitoring is paused. No checks are being performed. |
Preparing... | The monitor has been created or resumed but has not completed its first check yet. |
Up | The target is responding within the configured thresholds. |
Stopped | An initial failure has been detected. The system is performing confirmation checks before triggering an alert. |
Down | The failure is confirmed. An incident is created and alert contacts are notified. |
Incident Flow
When a UDP monitor detects an issue:
A check detects that the target is not responding as expected (e.g. packet loss exceeds threshold).
The system performs confirmation retries to verify that the issue is not transient.
If the failure is confirmed, the monitor transitions to Down, an incident is created, and your alert contacts receive a notification.
When the service recovers and checks pass again, the monitor returns to Up, the incident is resolved, and a recovery notification is sent.
API & MCP Access
Public API v3
UDP monitors can be created and managed through the public API v3. The API supports full CRUD operations for UDP monitors (type: UDP).
Example: Creating a UDP monitor for a WireGuard VPN endpoint:
{
"friendlyName": "WireGuard VPN - Office",
"url": "vpn.example.com",
"type": "UDP",
"port": 51820,
"interval": 60,
"timeout": 10,
"config": {
"udp": {
"packetLossThreshold": 5
}
}
}This checks the VPN endpoint every 60 seconds with 5% tolerance for packet loss. If the endpoint stops responding, the monitor goes down and your alert contacts are notified — before users start reporting they can't connect.
Note: UDP monitors are not available in the older public API v2.
MCP Server
The UptimeRobot MCP server (https://mcp.uptimerobot.com/mcp) also supports full CRUD operations for UDP monitors.
Example Use Cases
Use Case | Port | Why Monitor It |
VPN endpoints (WireGuard, OpenVPN) | 51820, 1194 | VPN downtime blocks remote access — and HTTP checks on the same server won't detect it |
DNS servers | 53 | A DNS outage silently breaks everything that depends on name resolution |
VoIP / SIP infrastructure | 5060 | SIP server downtime kills phone calls; catch it before users start complaining |
Game servers (Minecraft, CS2, Valheim) | 25565, 27015, etc. | Know immediately when your server is unreachable to players |
NTP servers | 123 | Time sync issues cause cascading failures in Kerberos, TLS certificates, and distributed systems |
RADIUS / authentication servers | 1812 | Network access control going down locks users out of the network |
STUN/TURN servers (WebRTC) | 3478 | Critical for video/voice apps — if STUN/TURN is down, calls and meetings fail |
Syslog collectors | 514 | Detect when your log pipeline goes dark before you need those logs for an incident |
SNMP monitoring endpoints | 161 | Monitor your monitoring infrastructure — know if your SNMP collectors go offline |
Voice chat servers | 64738 | Make sure your voice server stays reachable |