Six Follower Account Health Checks Tradovate Operators Need

TradeDupe

September 29, 2026

10 min read

Operational checklist for Tradovate prop desks: six continuous follower checks, REST vs WebSocket mapping, action-ready alerts, reconciliation runbook,...

A follower account health check runs six things continuously: WebSocket connectivity and heartbeat liveness, OAuth token expiry, order acknowledgement and fill reconciliation, risk limit verification against auto-liquidation settings, rogue-trade detection, and latency between leader and follower execution. Tradovate exposes both REST and WebSocket surfaces, and a check that relies on only one will miss failures the other would catch. TradeDupe builds this monitoring directly into its copy-trading infrastructure for prop desks running multiple Tradovate accounts.

> TL;DR: > > - Connectivity and stream liveness need sub-second to one-second monitoring during trading hours to catch stalled WebSocket connections that could cause missed trades or errors. > - Risk limit settings, including auto-liquidation and flatten timestamps, must be verified directly on accounts to prevent auto-trades that violate desk policies. > - Alerts should include detailed evidence, severity classification, and actionable steps, with critical issues like rogue trades or auto-liquidation breaches sent via multiple communication channels. > - Combining REST checks for configuration and risk settings with WebSocket event monitoring ensures real-time detection of failures and stream stalls before they cause financial losses. > - Testing the monitoring system through deliberate failures and simulation is essential to confirm the effectiveness of alerts, recovery procedures, and overall reliability.

What belongs on your follower health checklist
How to implement checks using Tradovate's REST and WebSocket APIs
Reading risk settings straight from the follower account
Building alerts that operators can actually act on
Reconciling what was intended against what actually executed
Testing the system before it gets tested by a real failure
Why the desk still needs a human in the loop
TradeDupe: built for exactly this monitoring problem
Sources
FAQ

What belongs on your follower health checklist

A follower account can look fine on a dashboard and still be silently broken. The checklist below covers the failure modes that actually cost desks money, not just the ones that are easy to log.

Connectivity and stream liveness: track heartbeat presence, reconnect attempts, and sequence gaps in the event stream so a dropped socket doesn't look like a quiet market.
OAuth token validity: watch access token and refresh token expiry, and flag failed reauthorization attempts separately from execution errors.
Order lifecycle verification: confirm every order moves from submit to acknowledgement or rejection, then to fill, then to a position update and confirmation, with no step skipped.
Risk limits and auto-liquidation: check dailyLossAutoLiq settings, trailing max drawdown mode, and flatten or cancel timestamps against desk policy.
Rogue or unexpected orders: detect any trade on a follower account that didn't originate from the leader, and confirm per-account copy toggles are respected.
Latency and sync: measure the time delta between a leader's fill and the follower's fill, since a widening gap usually signals a queuing or connectivity problem before it becomes an outright miss.

Each follower account should carry a status of healthy, degraded, blocked, or manual review, updated in real time so an operator can scan a fleet of accounts at a glance instead of digging through logs one account at a time.

How to implement checks using Tradovate's REST and WebSocket APIs

Tradovate splits its data into two planes, and treating them as two separate diagnostic layers makes troubleshooting far faster: a REST call tells you what an account's configuration and risk state are right now, while a WebSocket subscription tells you what is actually happening to it in real time.

Verify OAuth first. Tradovate's OAuth token exchange returns access_token, refresh_token, expires_in, and refresh_token_expires_in. Treat a reauthorization failure as its own alert type, distinct from an execution error, because the underlying fix is different.
Pull REST account and risk state. Query the account list, position limits, and accountRiskStatus endpoints to confirm configuration matches what the desk expects before trusting any live data.
Subscribe to WebSocket events and confirm heartbeats. Order acknowledgements, fills, and account updates all arrive here, and event timestamps or sequence numbers reveal a stalled stream before an order silently fails to mirror.
Correlate every leader fill against a follower event. A fill with no matching follower acknowledgement within a defined window is the clearest signal of a broken mirror.

Frequency matters here. Event streams need sub-second to one-second attention because a stalled WebSocket connection during active trading is a live risk exposure, not a housekeeping item. REST reads can run on a scheduled interval or trigger on account-state changes, since configuration data doesn't shift as fast as order flow.

Pro Tip: Log the WebSocket sequence number alongside every processed event; a gap in the sequence is often the first sign of trouble, well before a human notices anything on the dashboard.

Illustration showing a gap in event sequence

Reading risk settings straight from the follower account

Copier logic can be perfectly configured and a follower account can still be exposed, because the risk limits that matter live on the account itself, not in the copying software. Desks should verify these settings directly rather than assuming they match policy.

Effective position limits: confirm pre-trade risk parameters on the follower account, since these govern what the broker will actually allow, regardless of copier settings.
Post-trade risk fields: read dailyLossAutoLiq, trailingMaxDrawdown, and flattenTimestamp values and compare them line by line to desk policy.
Automatic mismatch response: when a follower's settings are looser than policy, such as a missing auto-liquidation trigger or a disabled flatten rule, copying to that account should pause automatically and generate a high-severity alert rather than waiting for a human to notice.

Tradovate's account risk endpoints expose these fields directly, which means a health check can catch a misconfigured follower before it takes a trade, not after. TradeDupe's own approach to this problem, detailed in its leader risk controls, sizes trades to the strictest connected follower so a looser account never becomes the desk's weak point.

Building alerts that operators can actually act on

An alert that just says "error" wastes the time of whoever reads it. Every alert needs enough context that the person on call can act within seconds, not minutes spent reconstructing what happened.

Include owner, severity, evidence, and next action on every alert: the order ID, the relevant timestamps, the exact error text, and what the operator should do first.
Classify by severity: critical for a missing follower fill, an unexpected order, or an auto-liquidation event; high for authorization failures or repeated rejections; medium for degraded latency; low for routine reconnects.
Match delivery to severity: critical alerts go out by phone or SMS plus a redundant webhook to Discord or Slack, while lower-severity items can wait for an ops channel or a daily email report.
Keep a full alert history, including recovery actions taken, so reconciliation and any later review has a complete record.

Pro Tip: Test your escalation path the same way you test your code. An alert that fires correctly , but nobody reads is functionally the same as no alert at all.

Reconciling what was intended against what actually executed

The core reconciliation question is simple: did every leader order produce a matching follower execution, at the right size, price, and side? Answering it consistently requires a defined cadence and a defined record, not a one-off spot check after something already went wrong.

Correlate leader order IDs and fill timestamps against follower acknowledgement and fill records, flagging any mismatch in size, price, or side, along with any fill that never happened.
Run intra-session quick checks every few minutes during active trading hours to catch divergence while it's still cheap to fix.
Run a full end-of-day reconciliation that stores a complete snapshot of orders and positions for every connected account.
Retain the full record: order ID, leader timestamp, follower acknowledgement timestamp, fill quantity, fill price, any error codes, and the reconciliation result itself.
Snapshot state before and after any recovery action, so there's a clear before-and-after record if a position needed manual correction.

TradeDupe's guidance on preventing daily loss limit breaches walks through several of these mismatch scenarios in practical terms, which is worth reviewing alongside your own reconciliation design.

Testing the system before it gets tested by a real failure

A monitoring stack that has never seen a failure is an untested assumption. Provisioning evaluation accounts and deliberately breaking things is the only reliable way to know your alerts and runbook actually work.

Provision evaluation accounts through Tradovate's partner tools and set realistic risk parameters to mirror your live configuration.
Simulate the failure modes directly: force a token expiry, kill a WebSocket connection, trigger an order rejection, and push an account into auto-liquidation.
Exercise the full runbook, including pausing copying, contacting the broker, and confirming recovery, not just confirming that an alert fired.
Set a testing cadence and document results, in line with CFTC guidance on automated-trading controls and NIST's continuous monitoring framework, both of which treat monitoring as an ongoing program rather than a one-time setup.

Common gaps show up here fast: a missing auto-liquidation setting or a disabled flatten rule rarely gets caught until a simulated failure forces the question.

Why the desk still needs a human in the loop

Automation catches a stalled stream or a missing fill faster than any operator scanning a screen ever will, and that speed matters when order flow doesn't pause to wait for you. But a rogue trade that looks intentional, or a recovery decision with money already at risk, still needs a person to make the call. Operators have to keep kill switches tested and audit trails intact, not just trust that the alert fired correctly. TradeDupe's security and reliability design reflects that split: automated detection paired with controls an operator actually holds.

> — Andres

TradeDupe: built for exactly this monitoring problem

Running these checks by hand across a dozen follower accounts is not a realistic option for most desks, which is why TradeDupe builds the monitoring into the mirroring itself rather than treating it as a separate project.

TradeDupe

The platform connects to Tradovate through an OAuth flow that does not store passwords, and does not require running software on a desk's own PC or VPS. Every fill on a leader account mirrors to enabled followers over live WebSocket streams, typically with very low latency, with the health checks described above running underneath.

Rogue-trade detection flags any follower order that didn't originate from the leader.
Per-account copy toggles let an operator pause a single follower without touching the rest of the fleet.
Daily loss limits and profit targets are set directly on Tradovate, so the broker enforces them rather than the copier.
Dashboards, alerts, and a trade journal give an operator one place to watch account health instead of several.

TradeDupe works across Tradovate-based prop firms, and every plan, starting at $20 per month billed yearly, includes a 7-day free trial with one-click cancellation. If your desk is ready to see this running on your own accounts, get started with TradeDupe in about ten minutes.

Sources

FAQ

What is a follower account health check?

It's an automated set of checks run continuously on each connected Tradovate follower account, covering connectivity, order acknowledgement and fill reconciliation, risk limit settings, and rogue-trade detection. The goal is catching a broken mirror or a misconfigured risk setting before it costs the account money, not after.

How often should connectivity and latency checks run?

Event streams, including WebSocket order and fill events, warrant sub-second to one-second monitoring during active trading hours, since a stalled connection is a live risk exposure. REST-based configuration checks can run on a scheduled interval or trigger only when an account's settings change.

What should trigger an automatic pause on a follower account?

A follower account should pause automatically when its risk settings are looser than desk policy, such as a missing auto-liquidation trigger or a disabled flatten rule, or when a rogue trade appears that didn't originate from the leader. Both conditions should also generate a high-severity alert with full evidence attached.

Does TradeDupe run these checks automatically?

Yes. TradeDupe connects to Tradovate through official OAuth, mirrors leader fills to followers in real time, and includes rogue-trade detection and per-account toggles as part of its monitoring, with daily loss limits enforced directly by Tradovate. Every plan includes a 7-day free trial to test this on live accounts.

What's the difference between REST and WebSocket checks in this context?

REST calls confirm durable account state, such as configuration and risk settings, at a given point in time. WebSocket subscriptions confirm live event flow, including order acknowledgements and fills, so combining both is what reveals whether a failure is a stale connection, a rejected order, or a genuine execution mismatch.