A WebSocket that throws an error is easy. You see it, you handle it. The dangerous case is the one that goes quiet: the TCP connection is technically still open, the socket object still reports readyState === OPEN, and no data is arriving. Your application thinks it has a live feed. It has a corpse.
I ran into this building a perpetual futures grid trading system. The bot consumes a live exchange market feed over WebSocket and makes order decisions from it. A dropped feed that the client doesn't notice is not a cosmetic bug — it means the bot is reacting to a price snapshot that stopped updating minutes ago. Every layer of risk management downstream assumes the feed is current. When the feed lies, the whole system lies.
None of what follows is specific to trading. Any product built on a live feed — market data, order-status streams, chat, collaborative editing, IoT telemetry, live dashboards — has the same failure surface. The connection will drop. The question is whether your client notices, and what it does next.
The Four Problems Nobody Solves in the Demo
Every WebSocket tutorial shows you new WebSocket(url) and an onmessage handler. That code works on your laptop for the ten minutes you're testing it. In production — over weeks, across flaky mobile networks, NAT timeouts, load-balancer idle limits, exchange-side maintenance windows — four things go wrong that the demo never covers:
