WebSocket
WebSocket monitoring
The socket opens, and still says something.
Try it now
One check, from one place, right now, and nothing is saved. A monitor checks from every location we run and confirms a failure from a second continent before anybody is woken, which a single look cannot show you.
What it is for
Your chat, your live dashboard, your price feed, your collaborative editor, your game lobby: all of it is a WebSocket, and it is the part of a product that fails while every layer underneath stays green. The page loads, the API answers, the certificate is good, the port is open, and the socket never opens.
Or it opens and closes again two hundred milliseconds later, which from a user's side is a screen that quietly stops updating and that nobody reports as an outage. They refresh, it works for a minute, they give up. So this does not stop at the handshake: it watches the socket for a moment afterwards, the same way the TCP check can insist on a greeting rather than being satisfied by an open port.
And the one people actually lose money on: the feed that is connected and has stopped publishing. Give us a message to send and a pattern the reply has to match, or just a pattern, and a silent feed is a failure rather than a healthy-looking green row.
Like every check here, it runs from Amsterdam, New York and Singapore, and a failure is confirmed from a second continent before anybody is woken. How that works.
What you can set
Everything below is on the form when you add one, on every plan.
- Address
- A ws:// or wss:// address, with the path. A host and port is the TCP check, which is a different question.
- Send this first
- One text frame, sent as soon as the socket opens, for an endpoint that answers rather than publishes.
- Expected message
- A regular expression a frame has to match. Filling it in is what makes a frame required at all.
- How long to wait for it
- Seconds. Separate from the connection timeout, because a feed that publishes every thirty seconds is healthy and would fail a handshake-shaped deadline.
- Timeout
- How long the handshake itself may take.
- Confirmations
- How many other continents must agree before anybody is woken.
Questions
Why can I not just point the HTTPS monitor at it?
Because the healthy answer would be recorded as an outage. A WebSocket starts as an HTTP GET carrying Upgrade: websocket and a Sec-WebSocket-Key, and a server that answers a plain GET with 400 or 426 is behaving exactly as it should. An HTTPS monitor sees that status code and reports you down while you work perfectly.
What does the check actually do?
It completes the upgrade handshake, which means a 101 with the Sec-WebSocket-Accept derived from the key it sent, and then keeps the socket for a moment to see whether it stays open. Then it hangs up. It does not hold a connection between checks, so nothing about this looks like a client to your server.
My feed is quiet most of the time. Will that fail?
No. A socket that opens and says nothing is healthy unless you fill in an expected message, because a feed with nothing to publish is not a broken feed. Fill that in and the rules change on purpose: a frame is then required inside the wait you set, which is how you catch the feed that is connected and has stopped.
What is the difference between 1000 and 1011 in a close?
1000 is a normal closure and 1011 is the server saying it hit a condition it could not recover from, and both arrive as a socket that went away. The close code and reason are in the failure, rather than being flattened into disconnected, because they send whoever is fixing it to two different places.
Do you support Socket.IO, SignalR, STOMP or MQTT?
No, and we say so rather than implying otherwise. Those are framings layered on top of WebSocket, each with its own handshake and its own idea of a namespace, and a check that half spoke them would be worse than one that does not. The raw check still tells you the transport underneath them is up.
Does it check the certificate on a wss:// address?
Yes. A wss:// connection is verified against the public trust store like any other, so an expired certificate, a self-signed one or a hostname mismatch fails the check. The days remaining are a certificate monitor's question, and worth running alongside this one.
Can I check a socket on my own network?
No, and this is the one refusal we are least sorry about. A WebSocket to an internal address is a long-lived bidirectional tunnel opened by our infrastructure on a schedule, which is a worse version of a server-side request forgery than a one-shot fetch. The address is resolved immediately before connecting and a private one is refused.