Documentation

WebSocket Checks

About Websocket Checks

WebSocket Checks can be used to monitor the availability of RFC-6455 and Socket.io (0.9.X) compatible WebSocket services. WebSocket is a protocol providing full-duplex communications channels over a single TCP connection. It is designed to be implemented in web browsers and web servers, but it can be used by any client or server application. The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request. The WebSocket protocol makes possible low overhead interaction between a browser and a web site, facilitating live content and the creation of real-time games. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way a two-way (bi-directional) ongoing conversation can take place between a browser and the server.

When to use WebSocket Checks

WebSocket checks should be used to monitor the availability of WebSocket services. It can optionally send a string 'message' to the websocket as part of the check and also verify that any return data either contains or does not contain a particular text. For instance, you can have the WebSocket check send 'mycustomcall' to your WebSocket service and verify that the response from service contains 'you must log in'.

Using WebSocket Checks

To set up a WebSocket check,

1. Select WebSocket from the Check type drop down.
2. Give it a friendly label to identify this check in lists and notifications.
3. Enable Automated Diagnostics if you'd like detailed technical info about the failure that may help you troubleshoot a failure.
4. Set how often you want the check to run in the Check Frequency field.
5. Enter the target URI you want to check. It must be a valid WebSocket or Socket.io URI. Valid WebSocket URIs should start with either 'ws://' or 'wss://' and valid Socket.io URIs start with either 'http://' or 'https://'. You can include port numbers and paths. The following examples are all valid (although these are fictitious, don't actually use these URL's in your checks):
   • ws://mywebsocket.us
   • wss://mysecurewebsocket.com:8080
   • http://socketioservice.net
   • https://securesocketioservice.info:8800
6. If you'd like to send a 'message' to the WebSocket service, type the text into the optional 'Send to Socket:' field. If this field is left blank, the check will simply connect, then disconnect from your WebSocket service without sending any messages or inspecting any messages received from the service.
7. If you'd like to verify that particular text appears or does not appear in the WebSocket reply, type the text you're checking for into the optional 'Content String' field and set it to either 'Contains' or 'Does not contain'. Any messages received by the WebSocket are not inspected if this field is left blank.
8. Set a time out. The default 5 seconds works fine for most situations.
9. Set the Sensitivity. High is usually appropriate. Some hosts have intermittent periods of time when they don't respond quickly. For a visitor this might not be a big deal if it is intermittent, but it might mean you'll get more "FAIL" responses than you anticipate. In those cases, set the Sensitivity lower.
10. Set the notifications for this check. More information about notifications.

Other considerations

This check uses HyBi drafts 13-17 protocols for checks starting with 'ws://' and 'wss://'

Currently only Socket.io versions 0.9.x are supported and the URI must start with 'http://' or 'https://'