Ping, TCP & UDP monitors

Use these monitors for things that don't speak HTTP: servers, databases, mail servers, DNS and NTP servers, game servers and VPN endpoints. Server ping (ICMP) checks that a host answers at all, Port (database, mail…) checks that a TCP service accepts connections, and UDP port (DNS, game servers…) checks that a UDP service replies.

All three accept a public host name or IP address (IPv4 or IPv6). Hosts that resolve to private, loopback or other non-public addresses are rejected when you save, with Target resolves to a non-public address and cannot be monitored.

Ping (ICMP)#

A ping monitor sends a few ICMP echo requests from each check location and records the average round-trip time.

To create one, go to Monitors → New monitor, set What do you want to check? to Server ping (ICMP) and enter the Host or IP, for example example.com or 1.1.1.1. If you paste a URL, the scheme and path are stripped.

How it's judged. The check is up if at least one packet gets a reply, and down only if every packet is lost. The response time is the average round-trip time of the replies.

Timing. A ping run can take up to packets × (timeout + 2 s). That total is capped at the check interval minus 3 seconds; if your settings don't fit, the per-packet timeout is shortened automatically. For example, 4 packets with a 10-second timeout need up to 48 seconds, so on a 30-second interval each packet gets a shorter wait.

{
  "name": "Edge router",
  "type": "ping",
  "interval_seconds": 60,
  "config": { "host": "203.0.113.10", "packet_count": 4, "timeout": 5 }
}

In the API, timeout is in seconds for ping monitors. packet_count values outside 1–10 are clamped.

TCP port#

A TCP port monitor opens a connection to a host and port from each location. If the connection is accepted, the check is up. No data is sent and no TLS handshake is made; it tests that something is listening.

To create one, set What do you want to check? to Port (database, mail…), enter the Host and Port, or click one of the common ports: 80, 443, 22, 25, 587, 3306, 5432, 6379.

How it's judged. Up when the TCP connection is established within the timeout. Down when the connection is refused, times out, or the host can't be resolved. The response time is the time to connect, including the DNS lookup.

{
  "name": "Postgres primary",
  "type": "port",
  "interval_seconds": 60,
  "config": { "host": "db.example.com", "port": 5432, "timeout": 5 }
}

In the API, timeout is in seconds for port monitors.

UDP port#

UDP has no connections, so the only way to know a UDP service is alive is to send it something and get an answer. A UDP monitor sends one datagram and waits for a reply.

To create one, set What do you want to check? to UDP port (DNS, game servers…), enter the Host and UDP port, or click a common port: 53 (DNS), 123 (NTP), 161 (SNMP), 1194 (OpenVPN), 27015 (Source game servers).

Hex values can include spaces or colons between bytes and an optional 0x prefix, but must be whole bytes (pairs of hex digits).

How it's judged.

• Up: a reply arrives from the target within the timeout and, if you set an expected response, contains it.
• Down: no reply before the timeout (UDP request timed out), the host answers with ICMP "port unreachable" (UDP port … unreachable), or the reply doesn't contain the expected response.

Replies from any other address are ignored. When a host name has both IPv4 and IPv6 addresses, IPv4 is used.

{
  "name": "Game server query",
  "type": "udp",
  "interval_seconds": 120,
  "config": {
    "host": "play.example.com",
    "port": 27015,
    "udp_payload_format": "hex",
    "udp_payload": "ff ff ff ff 54 53 6f 75 72 63 65 20 45 6e 67 69 6e 65 20 51 75 65 72 79 00",
    "udp_expected_response": "ff ff ff ff",
    "timeout": 5
  }
}

Shared behaviour#

• Checks run from every location the monitor uses, at your check interval. See Regions & confirmation.
• A failed check is re-checked once after a short pause, when the re-check fits in the interval, before it's recorded as down.
• Failure threshold and Recovery threshold aren't shown in the dashboard for these types; they default to 1. The Confirmation period and Recovery period under Detection in the advanced options work as for HTTP monitors. See How alerting works.
• Run check now on the detail page runs one real check immediately.

Troubleshooting#

Ping fails with "does not permit ICMP" or "has no ping binary installed". That message comes from the check location, not your server. The location can't send ping checks; choose other locations for this monitor or use a TCP port monitor.

TCP check is down but the service works from my network. Your firewall may only allow certain source addresses. Allow the SutramX checker addresses listed at https://sutramx.com/bot.

UDP check always times out. The service probably needs a specific request before it replies. Set Payload to send to a valid request for that protocol, and make sure the port isn't firewalled.

"Host and port are required". TCP and UDP monitors need both a host and a valid port between 1 and 65535.