Check WebSocket handshakes on a schedule.
WebSocket monitors open a handshake against your ws:// or wss:// endpoint on a schedule. When connections stop opening, the alert reaches you before the support tickets do.
Test the path your HTTP monitor skips.
WebSocket traffic breaks in ways page loads don't. Upgrade headers stripped by a proxy, a load balancer that stopped doing sticky sessions, a certificate that only the socket endpoint serves: your site stays green while the realtime layer is gone.
A WebSocket monitor opens a real handshake through the same route your clients use. TLS is part of the check on wss://, with a per-monitor toggle for staging hosts on self-signed certificates.
- Real handshake against ws:// or wss://
- TLS errors on wss:// count as down
- Toggle for self-signed staging certificates
Stop at the handshake on purpose.
The check passes when the server completes the WebSocket handshake, then closes the connection immediately. No application messages are sent, so the monitor never injects fake traffic into rooms, queues or presence lists.
For behaviour beyond the handshake, pair it with an HTTP monitor against the service's health endpoint. JSON path matching on that endpoint covers application-level state the socket check deliberately leaves alone.
- Connection closed right after it opens
- No messages sent into your application
- Pair with an HTTP health endpoint for app state
Alert the owner when handshakes fail.
A failed handshake, a TLS error or a 10-second timeout puts the monitor in the down state and fires notifications on the channels attached to it.
13 native channels are available, so the frontend team's Slack and the on-call PagerDuty service can both hear about the same socket.
- Down on failed handshake, TLS error or timeout
- 13 native notification channels
For the features users notice breaking first.
Chat and collaboration apps
Messages that stop arriving get noticed in seconds, not minutes. A handshake check every minute means you usually know before the first user asks what happened.
Live dashboards and feeds
Prices, scores, telemetry. A frozen feed looks identical to calm data, which is why the connection needs a watcher independent of the numbers.
Presence and multiplayer backends
Who's-online lists and session sync ride on sockets. Monitor the endpoint in every region you serve from your own instance, no third party in the path.
See what it covers and what it doesn't.
Covered
- WebSocket handshake against ws:// and wss:// URLs
- TLS validation on wss://, with a self-signed override
- Timeouts after 10 seconds count as down
- Handshake time recorded per check
- Internal endpoints, since checks run from your instance
- Alerts on 13 notification channels
Out of scope
- Message exchange: nothing is sent after the handshake, so subscriptions and echo behaviour are not validated
- Protocols layered on top: rooms, auth flows and library-specific semantics are not exercised
- Long-connection stability: the check proves connections open, not that they survive for hours
For the technically curious.
A real client handshake
The check connects with a standard WebSocket client and waits for the open event. Whatever a browser would negotiate to reach your endpoint, the monitor negotiates too.
A 10-second budget
A handshake that has not completed within 10 seconds counts as down. Slow is a separate story the handshake-time chart tells long before the timeout trips.
Clean disconnect
The connection closes the moment it opens, so monitoring adds one short-lived connection per check instead of an idle socket sitting in your connection counts.
TLS where it matters
On wss:// the certificate is validated as part of the check, so an expired certificate on the socket endpoint surfaces even when your main site's certificate is fine.
Frequently asked questions
WebSocket monitoring opens a handshake against a ws:// or wss:// endpoint on a schedule. If the server completes the handshake the endpoint is up, if it fails or times out alerts fire on your channels.
No. Checkmate closes the connection immediately after the handshake completes and never exchanges application messages, so rooms, queues and presence lists see no artificial traffic.
Socket traffic takes a different path: upgrade headers, proxy timeouts and load balancer config all affect it separately from page loads. That gap is why the realtime path deserves its own monitor.
Yes. TLS is validated by default on wss://, and each monitor has an ignore-TLS-errors toggle for staging environments running on self-signed certificates.
Pair the WebSocket monitor with an HTTP monitor against your service's health endpoint. JSON path matching on the HTTP check validates application state while the socket check validates the connection path.
Checkmate is one. It is open source under AGPL-3.0 and self-hosted, with unlimited monitors and no per-endpoint pricing.
