Different questions need different checks
Suppose a public service stops answering, but the website on the same host still loads. An HTTP check tells you about the website. It cannot establish whether a different protocol is working or whether the host responds to an ICMP echo.
PageLantern’s Ping and UDP monitor types add those specific checks to the same workspace. You can keep protocol results, response times, incidents and notifications together while preserving what each measurement actually tells you.
Ping checks public-host reachability
A Ping monitor sends a real ICMP echo request and waits for an echo reply. A reply records availability and round-trip latency; a timeout or unreachable target records a failed check. Supported targets include public hostnames and IPv4 or IPv6 addresses.
This is useful when you want a separate reachability signal alongside an application check. Remember that some firewalls deliberately discard ICMP. A failed Ping does not automatically mean a website on that host is unavailable.
UDP checks require an answer
A UDP monitor sends one datagram to a public host and port, then waits for a reply from that peer. Choose a UTF-8 text or hexadecimal payload. You can accept any received reply, require particular bytes within the response, or require an exact match.
For a service designed to answer PING with PONG, an exact-response check tests that expected exchange. Sending the packet alone never counts as success. A timeout fails the check even though UDP itself does not require a server to acknowledge every datagram.
Create the check and inspect the result
Open Advanced setup and select Ping / ICMP or UDP service. Enter the public target, choose the interval and timeout, and add the UDP payload and response rule when needed. Save the monitor, then use Run check to inspect an actual protocol result.
Both types use your configured failure-confirmation thresholds, recovery behavior and alert settings. If a service intentionally takes time to answer, choose a timeout that reflects its expected behavior rather than compensating for repeated failures after the fact.
Keep the scope clear
These checks run from the primary monitoring location; satellite confirmation is not offered. Private, loopback and other restricted addresses remain blocked by default. IPv6 checks also depend on an available IPv6 network route.
UDP payloads and expected matches are limited to 1,024 decoded bytes. An empty reply is accepted only by Any reply mode. Use an application-specific request the service understands, and retain an HTTP or API check when you also need to verify application behavior.