---
title: WebSocket monitors
description: Check that a WebSocket endpoint accepts connections, and optionally that it replies with what you expect.
sidebar:
  label: WebSocket
---

{/* Source of truth: packages/shared/src/monitors.ts — wsConfigSchema
    (WEBSOCKET monitor type). */}

A WebSocket monitor completes the upgrade handshake to a `ws://` or `wss://`
URL. Optionally it then sends a message and checks the reply.

## Configuration

| Setting | Allowed values | Required |
| --- | --- | --- |
| `url` | a `ws://` or `wss://` URL, up to 2048 characters | yes |
| `sendMessage` | text to send once connected | no |
| `expectedMessage` | text the reply must contain | no |

## Handshake-only checks

With neither message field set, the monitor proves the endpoint accepts
connections. That catches an expired certificate, a proxy that has stopped
forwarding upgrade headers, and a backend that is down — the most common
WebSocket failures.

## Round-trip checks

Setting both fields turns the check into a real round trip: Glowo connects,
sends `sendMessage`, and waits for a reply containing `expectedMessage`.

This catches the failure that a handshake check misses — a server that accepts
connections but has stopped processing them. If your protocol has a ping or echo
frame, use it here.

:::note
Reverse proxies are the usual culprit in WebSocket outages. A proxy that drops
`Upgrade` and `Connection` headers, or enforces a short idle timeout, breaks
WebSockets while leaving ordinary HTTP on the same host perfectly healthy — so
your HTTP monitor stays green. Watch both.
:::

## Timeouts

The shared `timeout` covers the whole exchange: connection, handshake, and — if
configured — the send and reply. Give a round-trip check more headroom than a
handshake-only one.