Bracket Orders Cancelled After NT8 Restart — Any Solution for Managed Strategies?

Desktop SDK - Strategies
1

Bracket Orders Cancelled After NT8 Restart — Any Solution for Managed Strategies?

I’m running a fully automated NinjaScript managed strategy on MNQ futures from a Chicago VPS. The strategy uses 3 contracts with multi-target exits (TP1/TP2/TP3), each with its own SetStopLoss() and SetProfitTarget() bracket.

[The Problem]

I experience intermittent connection drops on my VPS (1-2 times per day, Tradovate connection). When this happens and NT8 needs to be restarted, all bracket orders on existing positions get cancelled. The historical recalculation during restart fails to match the original orders because even a small price/timing difference causes a mismatch — and NT8 cancels any unmatched orders.

This leaves open positions completely unprotected. No stop loss, no profit target. For anyone running automated strategies on futures overnight, this is a critical risk.

[What I’ve Tried]

I’ve tested every Start Behavior option:

  • AdoptAccountPosition: position is recognized, but SetStopLoss()/SetProfitTarget() do NOT work on adopted positions in Managed approach (confirmed via Sim testing and NT8 support responses)
  • Immediately Submit / Immediately Submit, Synchronize Account: bracket matching fails due to price mismatch during historical recalculation
  • Wait Until Flat: no recovery at all

None of these preserve the original bracket orders after a restart.

[Current Workaround]

My only option right now is to detect the restart and immediately market-close all positions. This prevents unprotected exposure, but it also cuts winners short and locks in unnecessary losses. It’s a defensive measure, not a real solution.

[What I’m Looking For]

  1. Is there any way in Managed approach to preserve or re-establish bracket orders on an adopted position after NT8 restart?
  2. Has anyone solved this without converting the entire strategy to Unmanaged approach?
  3. Are there any other workarounds or third-party solutions that address this?
  4. For those who converted to Unmanaged approach: does SubmitOrderUnmanaged() reliably handle OCO grouping, position tracking, and order modification (ChangeOrder) in live trading? Any unexpected issues or limitations compared to Managed approach?

I know I’m not the only one dealing with this — connection drops on NT8 are well-documented across brokers (Tradovate, Rithmic, NinjaTrader Brokerage). For anyone running 24/7 automated strategies, this is arguably the biggest gap in NT8’s architecture.

Any insights or experiences would be greatly appreciated. Thanks.

2 Likes
2

You hit the exact architectural wall that makes the standard managed approach entirely unusable for serious overnight automated execution, the moment NinjaTrader restarts or recovers from a VPS connection drop its historical recalculation engine tries to reconstruct the theoretical trade lifecycle and if there is even a single tick of price drift or timing mismatch between the historical feed and your actual filled order at Tradovate the platform panics and kills the trailing brackets to prevent a sync error. Relying on AdoptAccountPosition under the managed framework is a dead end because the platform loses the internal pointers to the original OCO group tokens and refuses to attach new managed stop or target brackets to a pre-existing position

The only deterministic solution to this architecture flaw is abandoning the managed wrapper completely and migrating the engine to an unmanaged approach using SubmitOrderUnmanaged where you gain low-level control. In an unmanaged framework you handle persistence manually by overriding the OnStateChange method during the transition to the historical data state so that when the strategy wakes up it actively queries the live account position directly from the execution provider and manually spawns custom asynchronous OCO bracket strings based on the actual average entry price rather than relying on the platform to guess the historical fills. It takes more development overhead to build a custom state manager but it is the only way to run 24/7 futures systems without coming back to an unprotected position after a minor network drop