The WebSocket That Lies: Why Liveness Detection Beats Reconnect Logic

A dev.to post on WebSocket reconnection makes a point worth taking seriously: the failure you can handle is the one that throws, and the failure that hurts you is the one that goes quiet, with the TCP connection technically open, the socket object still reporting `readyState === OPEN`, and no data arriving ^[1]. That inverts where most client effort goes, because the backoff-and-replay machinery everyone writes is downstream of a decision nobody makes: declaring the connection dead.

The author's example is a perpetual futures grid trading bot that consumes a live exchange market feed over WebSocket and places orders from it ^[4]. A feed that stops updating without the client noticing means the bot is reacting to a price snapshot that went stale minutes ago, while every downstream risk check assumes the data is current ^[5]. The same failure surface applies to order-status streams, chat, collaborative editing, IoT telemetry, and live dashboards ^[6].

The post names the core mistake plainly: trusting `readyState`, which reports what the local socket object believes rather than whether packets are moving ^[3]. A NAT table entry that expired, or a phone switching from Wi-Fi to cellular, leaves the socket in `OPEN` with nothing coming through ^[3]. `onclose` does not always fire, and a silently half-open socket can sit there for minutes [c5a].

The proposed fix is an application-level heartbeat: send a ping on an interval, expect a pong within a deadline, and if the pong does not arrive, tear the connection down yourself rather than waiting on a TCP timeout that may be minutes away ^[10]. The sample implementation is deliberately small. A `setInterval` sends the ping and arms a `setTimeout` death deadline; any inbound pong clears that timer; if it expires, an `onDead` callback fires and the socket's own claim to be OPEN is ignored ^[14].

The sizing argument is the part to copy. RFC 6455 defines native ping/pong frames and the Node.js `ws` library exposes them, but browsers give no access to control frames, so browser clients send an application-level heartbeat message instead ^[11]. Either way, the timeout must be shorter than any upstream idle limit you know about; load balancers commonly cut idle connections at 60 seconds, and the post suggests a 20-second interval with a 10-second timeout ^[12]. That puts worst-case detection at roughly 30 seconds, half the idle limit it is meant to beat ^[15].

The second detail is the one that explains why teams get away with bad heartbeats for a long time. Any inbound traffic is proof of life, so on a firehose delivering market data every few milliseconds a missed pong is nearly impossible ^[13]. The heartbeat earns its keep during quiet periods, when a feed with nothing to say is indistinguishable from a feed that has died ^[13].

What to check in your own client: whether anything at all measures time since last inbound message, and whether that threshold is set below your load balancer's idle cut ^[12]. Then the three problems that follow detection, which the post lists and most demos skip: reconnecting without a thundering herd, since ten thousand clients returning at once will knock the server over again [c5b]; restoring subscriptions, because a fresh socket has none and the server has forgotten who you are [c5c]; and the gap, because messages published during the outage are gone unless you do something about it [c5d].