NinjaTrader Crashed During a Live Session — Exact Recovery Steps for Prop Accounts

NinjaTrader crashes happen. Rarely on a stable VPS, but they happen. When they do during a live session with open positions across multiple funded accounts, the first 60 seconds matter most. Here's the sequence, executed calmly.

Immediate Response: The 60-Second Protocol

Step 1 (0-10 seconds): Assess the situation, don't panic-close.
Don't immediately close everything manually. You don't know yet whether NinjaTrader crashed cleanly (positions still open at the broker, just disconnected) or whether something more complex happened. A premature manual close could create a worse state than the crash itself.

Step 2 (10-30 seconds): Log into each broker directly.
Open your browser and navigate to the Tradovate web app (or Rithmic portal if applicable). Log into the accounts with open positions and check their actual current state — what positions are open, at what size, what are the current P&L levels?

This is the ground truth. Everything else is suspect until you've verified directly at the broker.

Step 3 (30-60 seconds): Decide — manage manually or restart NT immediately?
If positions are moving against you significantly and you cannot restart NinjaTrader quickly: close positions manually via the broker's web interface. A clean manual close is better than watching positions deteriorate while NT reboots.

If positions are stable or moving in your favor: prioritize NT restart. Every second of NT being down is a second Copilink isn't monitoring and protecting those positions.

Restarting NinjaTrader

1. If NinjaTrader is still visible but frozen: force quit via Task Manager (Ctrl+Shift+Esc → NinjaTrader → End Task)
2. Wait 10 seconds for all NT processes to terminate (check Task Manager to confirm)
3. Restart NinjaTrader
4. NinjaTrader will attempt to auto-reconnect to configured broker accounts on startup — wait for all connections to establish (typically 30-60 seconds)
5. Once connected, NinjaTrader will sync position state from the broker — open positions should populate automatically

After restart, verify the position state in NT matches what you saw directly in the broker portal. If they match: you're recovered and Copilink will resume monitoring from the current state.

If they don't match: there's a sync issue. See the position reconciliation guide for resolving divergent NT/broker states.

After Recovery: What to Check

□ Positions match between NinjaTrader and broker portal on all accounts.
Go account by account. NinjaTrader's Positions tab vs. broker web interface. Any discrepancy needs investigation before placing new trades.

□ Copilink shows all follower accounts as active.
The copier may have lost its state during the crash. Verify each follower account is listed and active in the Copilink panel. If any accounts need to be re-added to the follower list, do this before continuing.

□ Daily P&L and drawdown status is accurate.
NinjaTrader may show incorrect cumulative P&L after a crash/restart until the data syncs fully. Cross-reference against the broker portal's daily P&L for each account.

□ Any daily loss limits that should have triggered did trigger.
If any account hit its daily loss limit during the crash window while Copilink wasn't monitoring, check whether those accounts are in a loss position that would have triggered a lockout. If so, manually lock them now and investigate before trading again.

Preventing This in the Future

NT crashes on a stable, properly specced VPS are rare. The most common causes:

• RAM exhaustion: Too many chart windows, indicators, and account connections for the available RAM. Closing unnecessary charts or upgrading VPS RAM resolves this.
• NinjaTrader version instability: Some NT build updates introduce bugs. If crashes become frequent after an update, rolling back to the previous stable version is an option.
• Disk I/O spikes: Slow storage (HDD) causing NT to freeze during data writes. NVMe SSD eliminates this.
• Third-party add-on conflicts: A misbehaving NinjaScript add-on can crash the entire NT instance. Test new add-ons in isolation before deploying in a live multi-account setup.

The standard prevention: Chicago VPS with NVMe storage, appropriate RAM for your account count, and a lean set of tested add-ons. The crash should be rare enough that the recovery protocol above feels like excessive preparation — until the one time you actually need it.