Summary
Add native check types that can send a UDP protocol handshake and validate the response. Specifically a STUN Binding Request, a TURN Allocate, and a SIP OPTIONS or REGISTER.
Problem
Customers running VoIP, UCaaS, or any real-time media infrastructure need to know their STUN and TURN servers are actually answering at the protocol layer, not just that a socket is open. STUN is the NAT traversal lookup and TURN is the relay fallback when a direct media path can't be negotiated, so nearly every call depends on both being healthy. Today there's no way to monitor either natively in Checkly.
What we can cover today, and where it falls short
TCP checks confirm SIP signaling ports (5060, 5061) and the TURN TCP fallback (3478, 5349) are listening, but a listening socket proves nothing about protocol health: the service can be crashed, misconfigured, or holding a stale shared secret and still accept the connection. Browser checks with WebRTC exercise the full ICE negotiation end to end from a user seat, which is valuable but slow, expensive, and doesn't isolate which component failed. Heartbeats let a customer keep an external probe alive and alert on missed pings, which works but means they're still maintaining the script we're supposed to be replacing. DNS monitors use UDP under the hood but aren't exposed as a general prober. Traceroute diagnoses where packet loss lives but doesn't handshake either, so it's complementary rather than a substitute.
Requested capability
A UDP-capable check type where the user specifies host, port, and protocol (STUN, TURN, SIP), with assertions on response code and latency. TURN would need optional credential support for the Allocate.
Please authenticate to join the conversation.
In Review
π‘ Feature Request
Check Types
1 day ago

Shawn Harris
Get notified by email when there are changes.
In Review
π‘ Feature Request
Check Types
1 day ago

Shawn Harris
Get notified by email when there are changes.