Tradovate WebSocket 'Connection to Remote Host Lost'

When your bot is streaming ES or NQ quotes around the clock, nothing kills a strategy faster than a Tradovate WebSocket that quietly dies with “Connection to remote host was lost.” It's one of the most common Tradovate API headaches: the socket runs fine for hours, then drops, very often right around the 24-hour mark, and takes your live market data and order routing down with it. Sometimes you'll see it as a raw WebSocket close (code 1006, “abnormal closure”). Sometimes it looks like a mass disconnection. Sometimes it's just a dead feed that never throws an exception at all.

There's no single magic setting that fixes this. What actually keeps a socket alive is a handful of habits working together: 2.5-second heartbeats, automatic reconnection, token renewal, and cycling the connection before it goes stale. PickMyTrade bakes this reconnect-and-re-auth logic in, so your TradingView alerts keep reaching Tradovate even when a hand-rolled socket would have quietly fallen over.

What "Connection to Remote Host Was Lost" Means

“Connection to remote host was lost” is Tradovate's way of telling you the WebSocket to its servers is closed and no longer usable. It's a transport-level event, not a rejected order, not a bad request. The pipe itself went away. Under the hood this usually shows up as an abnormal WebSocket close (close code 1006), meaning the connection dropped without a clean close handshake, so your client can't always tell you exactly why.

Here's the part that trips people up: a lost connection is normal and expected on a long-lived feed. Networks blip, load balancers recycle, idle sockets get pruned, tokens expire, and very long sessions get cycled server-side. Even a perfectly well-behaved client streaming live data can lose the socket after enough hours of uptime. So the goal isn't a socket that never drops, that's impossible. The goal is a client that notices the drop instantly and recovers on its own, without you babysitting it.

That distinction matters for risk. If your feed dies silently and your code still assumes it's connected, you can miss fills, miss stop triggers, or fire orders into a stale view of the market. Treat every WebSocket as disposable and every disconnect as a routine event to handle, not an emergency.

Top Causes of a Dropped Tradovate WebSocket

1. Missed heartbeats (server idle timeout)

This is the single most common cause. Tradovate's WebSocket protocol requires the client to send a heartbeat every 2.5 seconds, a frame whose text is an empty array, [], to prove it's still alive. If the server goes 2.5 seconds without hearing from you and isn't actively streaming data to you, it treats the client as idle and closes the connection. And here's the catch: while the server is actively pushing messages (say, a busy market-data subscription), it won't send its own heartbeats, so keeping the [] frames flowing is entirely on your client.

2. Browser / timer throttling

If you build in the browser and schedule heartbeats with setInterval or setTimeout, you're walking into a subtle trap: browsers throttle timers in background or inactive tabs, stretching your 2.5-second interval out to several seconds. The moment it exceeds the window, the server closes the socket. Don't lean on setInterval, time your heartbeats from the last message you actually received instead.

3. Access token expiry

Your WebSocket is authorized once with an access token, and that token has a limited lifespan, around 90 minutes from creation per Tradovate's API docs. When the token behind an active connection expires, the connection is no longer authenticated and can be dropped. A long-running client that never renews its token will watch the socket die on a predictable cadence.

4. Long-lived connections over ~24 hours

Maintaining a connection for more than 24 hours is a recognized cause of drops on its own. Even with perfect heartbeats and a fresh token, a socket that's been open for roughly a day is a prime candidate to get recycled server-side. That's why a raw connection that “worked all afternoon” mysteriously dies overnight.

5. Reconnect storms and the session limit

When a socket drops, naive code often hammers the server with immediate, back-to-back reconnect attempts. That can trip Tradovate's request rate limits and make things worse, and repeatedly re-authenticating (instead of renewing) can bump you against the concurrent-session cap. The result is a client stuck in a reconnect loop that never stabilizes.

How to Fix a Lost Tradovate WebSocket Connection: Step-by-Step

Send a Heartbeat Every 2.5 Seconds, the Right Way

This one habit resolves the majority of “connection to remote host was lost” reports, because it directly satisfies the server's idle-timeout rule.

Add Automatic Reconnect and Resubscribe Logic

Renew the Access Token and Re-Authorize the Socket

Confirm API Access Is Enabled and You're Within the Session Limit

Proactively Cycle the Connection Before 24 Hours

Rather than waiting for the server to drop a day-old socket, get ahead of it. On a timer, comfortably under the ~24-hour ceiling, close your existing WebSocket cleanly and open a new one with a freshly renewed token, then re-authorize and resubscribe. Since your reconnect path already exists (you built it in the step above), a scheduled cycle is just a controlled version of the same routine. It turns a surprise 3 a.m. disconnect into a planned, invisible refresh.

Troubleshooting Table

Prevent This with PickMyTrade

If your goal is simply to get TradingView alerts into Tradovate reliably, you don't have to hand-build and babysit all of this socket plumbing yourself. PickMyTrade sits between TradingView and Tradovate and keeps the connection healthy for you.

• Managed Reconnect Logic, automatic reconnect, re-authorization, and resubscription on every drop, so a lost socket recovers without you writing or maintaining the code.
• Token Renewal Built In, sessions are refreshed before they expire, keeping the connection authenticated instead of dying on the ~90-minute token clock.
• Connection Cycling, long-lived connections are recycled proactively, so the ~24-hour drop never catches your automation offline.
• Rate-Limit-Safe Routing, reconnects and order flow are spaced out to respect Tradovate's limits, avoiding the reconnect-storm lockouts that plague raw sockets.