WebSocket resilience

What this WebSocket check does

This tool opens the platform’s existing signed echo endpoint from your browser and sends six small, versioned application heartbeat messages. Each reply must match the exact current run, socket and sequence. It records opening time, individual application round trips, validated replies and the observed close code. These are ordinary WebSocket messages, not protocol ping and pong frames. The check accepts neither an arbitrary destination nor a user payload, and simply visiting this page does not open a socket.

Continuous control and deliberate reconnect

The continuous scenario uses one socket for all six exchanges. The reconnect scenario acknowledges messages 1–3, requests a normal close and verifies the resulting clean close event. It waits 500 ms, opens one fresh connection under the same bounded test lease, then acknowledges messages 4–6. The logical sequence continues in the diagnostic client; no server application state is resumed and no in-flight message is replayed. Unexpected failures stop the test instead of triggering additional retries.

Reading the result

A verified sequence means the six exact application replies were observed before orderly closure within this scenario. A missing, duplicated, unsolicited, binary, oversized or mismatched response prevents that result. The recovery interval starts at the observed first close and ends at the first validated reply on the second socket; it includes the chosen backoff, handshake and application exchange. A continuous run reports reconnect as not tested. Timing values include browser scheduling and server processing, so they cannot identify a network-only delay.

Bounded execution and server ownership

The client permits one outstanding heartbeat, a 250 ms observation interval after each reply and at most two sockets. Connect, reply and clean-close deadlines are three, two and one-and-a-half seconds respectively, inside a twenty-second run deadline plus bounded cleanup. Individual messages are capped at 256 UTF-8 bytes, and sending stops if the browser reports more than 1024 queued outbound bytes. The existing session coordinator owns the sockets and closes them on Stop or expiry. Existing server byte, message and concurrency quotas remain in force.

Privacy, limitations and useful comparisons

The 8 MiB admission allowance is reserved rather than sent. Signed short-lived session capabilities use the existing subprotocol envelope, not query parameters. The native browser may attach browser-managed cookies during its handshake; WebSocket does not expose Fetch credentials controls. Reports omit cookies, capabilities, payload contents, IP addresses and remote close reasons. Keep the tab visible, compare the continuous control with the deliberate reconnect, and export only the evidence you need. A generic browser socket error does not identify an HTTP rejection status, DNS failure, TLS failure or router fault. This test does not inject a physical outage, certify arbitrary application recovery or measure packet loss.

Method references and related tools

WHATWG WebSockets defines browser handshake, message and close semantics. Cloudflare WebSockets documents the existing endpoint runtime. W3C Resource Timing explains browser timing and protocol visibility. Cloudflare Workers Response API documents the controlled response mechanism. These standards do not certify the measured network path.

SSE stream stability · All tools · Overall measurement methodology