Your copier crashing does not close a single position. Every follower account stays exactly as it was at the broker: same symbol, same side, same size, same average price. Nothing at the broker knows anything changed, because nothing at the broker ever knew the copier existed. What dies is every future action the copier was going to take, starting with mirroring the master's exit.
When a trade copier dies mid-trade, follower positions stay open at the broker unchanged, because a broker position record holds account, symbol, side, quantity and average price and has no field naming the software that opened it. A dead copier produces orphaned positions nobody is managing, not flat accounts. Only protective orders already resting at the broker still bound risk, because every exit that lived inside copier logic, including the mirrored exit from the master, never fires.
What actually happens to open positions when a copier dies?
Nothing happens, which is the problem. A position at a broker is a record of account, symbol, side, quantity and average price. There is no field for "opened by copier." When the copier process exits, the broker emits zero events: no liquidation, no cancellation, no notification. The follower is in the market alone.
The list of things that stopped is longer than most traders assume: mirroring the master's exit, moving stops as the master moves them, scaling out, flattening at session end, enforcing a per-account risk cap, cancelling the resting leg of a bracket when the other leg fills. Every one of those was a future write, and future writes are exactly what a dead process cannot do.
The sharp version: if the master exits while the copier is down, the followers stay in that trade indefinitely. Follower risk stops being bounded by the master's discipline and becomes bounded only by whatever rests at the broker. The master account can be flat, green and closed for the day while four follower accounts are still short into a rally.
Which failure is it? Five modes with five different exposures
"The copier went down" describes five different events with five different consequences and five different fixes. Treating them as one thing is why most failover setups protect against the least dangerous one.
| Failure | What breaks | Follower exposure | Does auto-restart help? | Does anything alert? |
|---|---|---|---|---|
| 1. Copier process crashes, machine alive | Master link and all follower links die with the process | Positions frozen as-is, no future actions | Yes, but only if the restart reconciles | Yes, process exit is detectable |
| 2. VPS loses power or network | Everything, including the supervisor | Identical to case 1 | No, the supervisor is on the dead machine | Only from outside the machine |
| 3. Master link drops, followers connected | Inbound signal only | Held past the master's exit, no error anywhere | No, the process never exited | Only if you alert on link state |
| 4. One follower link drops | One outbound leg | That account silently diverges, then compounds | No | Only if you alert per account |
| 5. Copier alive, internal state wrong | Nothing, visibly | Wrong-size or phantom positions, acted on confidently | No, and a blind restart makes it worse | Usually not, and that is the danger |
Case 3 is the nastiest and the one nobody tests. Every follower connection is healthy, every dashboard is green, the copier is running and authenticated. It never learns that the master exited, because the socket carrying that news is dead or stalled. No error state exists, so nothing displays.
Case 4 does its real damage on reconnect, not during the outage. If the copier resumes applying master deltas ("master bought 1, so send 3") to a base that is now stale, every subsequent trade compounds the error instead of correcting it. Delta-based replication needs an absolute-state checkpoint or it drifts forever, the same mechanism behind ordinary position drift between accounts in multi-account copy trading, just accelerated.
The topology makes it concrete. Master platform on the left, copier in the middle, four follower accounts on the right. One inbound edge carries master fills into the copier; four outbound edges carry sized orders back out. Case 3 severs the single inbound edge and leaves all four outbound edges live, so the copier keeps confidently managing positions using news that stopped arriving. Case 4 severs one outbound edge, so three followers track the master and the fourth freezes at whatever it held. Same box, one different cut, two unrelated exposures.
Case 5 is the worst because nothing is down, so nothing alerts. The copier's ledger and the broker's reality separated and neither side noticed. Causes are mundane: a dropped fill event, a partial fill recorded as a full fill, a rejected order the copier assumed succeeded, or a firm-side auto-flatten the copier never saw. NinjaTrader documents this class of gap against itself. Its NT8 help guide states that MIT and simulated orders sitting in a TriggerPending state cannot be recovered by NinjaTrader if the provider does not offer native support, and that such orders show an "Unknown" state after connection recovery.
Where does your protective stop actually live?
An exit lives in one of three places and only two survive the copier dying. It can rest at the exchange, held by the matching engine itself, which on CME Globex covers the exchange-supported stop order types. It can live on the broker or platform server: MetaTrader 5 Stop Loss and Take Profit values, a broker-side bracket, any protection the venue keeps working while your client is closed. Or it can live in client software: your platform's local logic or your copier's logic. Category three dies with the process holding it.
MetaQuotes documents the distinction more plainly than any copier vendor will. MetaTrader 5's own help says a Trailing Stop "is executed in the trading platform rather than on the server (like Stop Loss or Take Profit). This is why it will not work, unlike the above orders, if the platform is off." Two lines drawn identically on the same chart, with completely different survival properties.
Do not generalise that to every platform. Others implement the same-named feature server-side, where it keeps working with the client closed. So "trailing stops are client-side" is wrong as a rule and right as a suspicion: check your own platform's documentation, and where it does not say plainly which side executes, assume client-side. The same check applies to brackets and OCO, which on CME futures are often software running at your broker or platform rather than an object the exchange holds. NinjaTrader's help guide lists NinjaTrader itself, FOREX.com/City Index and Rithmic as simulating OCO locally, with Continuum/CQG, FXCM, Interactive Brokers and TD Ameritrade handling it natively at the server. That page still carries retired broker brand names, which tells you how fast vendor documentation ages, so read the current version for your own connection.
A bracket that only exists inside your copier is not protection. It is a promise from a process that can die.
One layer cuts the other way. CME's Cancel on Disconnect service cancels resting futures and options orders when a registered iLink session disconnects, and CME states this does not include GTC and GTD orders, with registration based on session ID and trader ID. Changing that registration runs through clearing firm administrators, not through you. Your copier losing its socket does not disconnect your broker's Globex session, so a genuinely exchange-resting stop keeps working through your outage. What kills your protection is almost never the exchange. It is software that was never at the exchange in the first place.
If a protective order does not appear as a working order inside the follower's own broker platform, it does not exist once the copier stops running. A line on the copier's screen proves only that the copier intends to act.
The worked example: the master exits, the followers do not
Master is short 3 ES at 5,800.00, mapped at 2 ES per follower across 4 followers. The copier dies at 10:12. The master covers at 5,796.00 and banks 4.00 points x $50 x 3 contracts = $600. The exit reaches nobody. The trader notices at 10:31 with ES at 5,812.00 and flattens manually: each follower loses 12.00 points x $50 x 2 contracts = $1,200, so 4 x $1,200 = $4,800. A live copier would have made each follower 4.00 x $50 x 2 = $400, so 4 x $400 = +$1,600. The swing caused purely by a dead process is $4,800 + $1,600 = $6,400. The master's screen showed a winning trade the entire time.
Now price the stop question on a single account. A follower is long 2 ES at 5,800.00 with a stated 10-point risk plan. Case A, the stop rests at the broker as a working stop order: it fills at 5,790.00 for 10.00 x $50 x 2 = $1,000. Case B, the "10-point stop" exists only as copier logic that would have sent a market order, and the copier is dead: the position is discovered at 5,742.00, for 58.00 x $50 x 2 = $5,800. Same trade, same stated plan, $4,800 apart. Against an illustrative $2,000 daily loss limit (check your own firm's current figure, since these vary by firm and change), Case A uses half the limit and Case B is 2.9x it.
Why reconcile-on-reconnect is the single most valuable behaviour
Reconciliation helps cases 3, 4 and 5 at once, and it is a specific protocol act rather than a philosophy. On reconnect the copier must query the broker for current positions and working orders per account (a stop it believes is resting may have been cancelled), diff that against its own ledger per account, symbol and side, then resolve the difference explicitly: converge to broker truth and re-align to the master, or halt and alert. It must never assume its own ledger is correct.
These are first-class calls, not bespoke hacks. FIX defines Order Mass Status Request (MsgType=AF) with MassStatusReqID (584) and MassStatusReqType (585), returning Execution Reports with an ExecType of "Order Status" and the final one flagged by LastRptRequested (912). The cTrader FIX API specification documents Order Status Request, Order Mass Status Request, Request for Positions and Position Report among its supported messages. A copier that does not reconcile is not failing because the broker would not tell it.
Four steps, in order. The socket reconnects. The copier asks the broker for positions and working orders. The copier diffs that answer against its own ledger row by row. The copier either writes orders to close the gap or halts and pages a human. A blind-resume copier jumps from step one straight to acting on the next master signal, and that missing middle is the whole bug.
Concretely: on reconnect the copier's ledger says follower F is long 4 MES. The broker's Position Report says F is long 6 MES. The delta is +2. If the copier trusts itself and mirrors a master "close all" as sell 4, F is left long 2 MES. At an index level of 5,800.00 that is $5 x 5,800.00 = $29,000 of notional per contract, so $58,000 sitting unmanaged, and a 30.00-point adverse move costs 30.00 x $5 x 2 = $300 that no ledger will explain. Selling 6 converges to broker truth. Halting and alerting is also acceptable. Selling 4 is the bug.
How long that blind window stays open usually comes down to one config value. Take a copier that declares a link dead after 3 missed heartbeats. On a fast WebSocket cadence of 2.5 seconds, detection alone costs 3 x 2.5 = 7.5 seconds, before reconnect, re-auth and a position snapshot even begin. Across 4 followers holding 2 ES each, 8 contracts are exposed, so every 1.00 point of drift in that window is 8 x $50 = $400 of unmanaged movement. Now run the same copier on cTrader's documented default FIX heartbeat of 30 seconds: detection alone becomes 3 x 30 = 90 seconds, a twelve-fold longer window from one number nobody looks at. That same specification notes that setting HeartBtInt to 0 means no heartbeat is required, which lets a copier sit on a dead socket believing it is connected. Cadence is per vendor and per config, so read your own connection's documented value.
One related hazard: a copier that restarts and replays the master's trade history from an event log can re-open positions it already copied, doubling exposure with no redundancy involved. Reconciliation must key on current broker positions, never on a replayed event stream. The design rule underneath all of this: the broker is the source of truth and the copier's state is a cache. Nearly every serious defect here comes from treating the cache as authoritative.
Why running two copier instances can be worse than running one
Two instances with valid credentials to the same follower account both receive the same master event and both act, and neither is wrong from its own point of view. With no lock, both mapping 3 ES per 1 master ES to follower F, a master buy of 1 ES produces buy 3 from instance A and buy 3 from instance B: F is long 6. With an 8-point stop, intended risk was 3 x 8 x $50 = $1,200 and actual risk is 6 x 8 x $50 = $2,400, exactly double, with double the margin consumed.
This often leaves no trace. When the master flattens, both instances send sell 3, F ends flat, and the end-of-day report looks clean. The doubling existed only while the trade was open, which is precisely when it mattered.
The asymmetric version leaves damage behind. Same setup, F long 6, then instance A dies. Instance B's ledger says F is long 3 because B only ever recorded its own orders. The master flattens, B sends sell 3, and F is left long 3 contracts that no software manages and no ledger records. A 20.00-point adverse move on that orphan costs 20.00 x $50 x 3 = $3,000, unreported.
The fix is mutual exclusion, not more copies. Exactly one instance holds a lease with a TTL, or the instances run leader election, with Raft the standard reference. Standby instances may connect and read, but must not send orders unless they hold the lease.
The TTL tradeoff is genuinely uncomfortable. A short TTL gives fast failover and raises the chance that a stalled-but-alive leader loses its lease while still able to send orders, which is split brain. A long TTL is safe and slow, meaning minutes of unmanaged positions. The textbook mitigation is a fencing token, a monotonically increasing lease number the downstream system rejects if stale, but broker order-entry APIs do not generally accept one. A copier can only self-fence, which is strictly weaker, so treat split brain as reducible rather than eliminable.
Price the trade honestly. A single instance available 99.5% of the time is down 0.005 x 30 x 24 x 60 = 216 minutes per 30-day month. Two instances with a correct lock and truly independent failures would be down 0.005^2 = 0.000025 of the time, which is 43,200 x 0.000025 = 1.08 minutes per month. That buys about 215 minutes. Independence is the load-bearing assumption and real deployments rarely have it: same provider, same region, same config, same bad release. Against those 215 minutes, one split-brain event doubles risk from $1,200 to $2,400 inside a single trade, and on a funded account a breach is not recoverable by any amount of uptime.
One more trap: the watchdog that flattens all followers when the copier dies. It converts an availability problem into a realised-loss problem, because a 20-second blip flattens positions the strategy would have held through. It also relocates the single point of failure rather than removing it, since the watchdog must itself stay alive and connected.
The pre-flight checklist you can run this week
Six steps, one small live position, roughly an hour. Use the smallest contract you trade.
1. Verify the stop exists at the broker. Open a small live position through the copier, then look in each follower's own broker platform, not the copier UI, and confirm a protective order appears there as a working order.
2. Kill the process ungracefully. End-task or kill -9, never the copier's own shutdown command. Graceful shutdown paths often run cleanup that a real crash never executes, so a clean shutdown test proves nothing about a crash.
3. Exit the master while the copier is still dead. Watch the follower stay open. That is the exposure you are actually carrying, made visible in about sixty seconds.
4. Restart and watch what it does first. It should query and report current positions per account, then converge or flag the mismatch. If it silently resumes as though the follower were flat, it is a blind-resume copier and cases 3, 4 and 5 are all unhandled.
5. Test the cases separately. Cutting the VPS network interface tests case 2. Taking only the master platform offline tests case 3. Revoking one follower's credentials, letting the master do a full round trip, then reconnecting tests case 4. Killing the process only ever proves case 1. This belongs in the same session as the rest of your pre-live copier testing.
6. Confirm alerts fire on link down, not just on process exit. Cases 3 and 5 never produce a process exit, so an alert wired to process death is silent for exactly the failures that hurt most.
What to build first, and when a copier is the wrong tool
Ranked by value per unit of effort for an individual trader: first, broker-resting protective orders on every follower account. Second, fast alerting on link loss. Third, auto-restart with reconciliation, remembering that a supervisor such as systemd Restart=on-failure or a Windows service recovery action covers case 1 only, cannot cover case 2 because it lives on the same dead machine, and does nothing for cases 3, 4 or 5 where the process never exited. Only then, a second instance behind a proper lease. Most traders should stop after the second or third item and put the remaining effort into a VPS setup that fails less often rather than a second machine that fails in new ways.
There are also cases where a copier is not the answer. If you trade one funded account, a copier adds a failure mode and buys you nothing, so trade it directly with stops resting at the broker. If your exits are discretionary and your stops are mental, no failover architecture helps, because a copier faithfully replicates an unbounded risk profile and adds a process that can die halfway through it. And if your firm restricts copy trading between accounts or across users, all of this is moot. Business continuity and disaster recovery planning is a genuine regulatory obligation for NFA member firms under NFA Compliance Rule 2-38, but that duty sits with the firm and covers the firm's own systems. Nothing in it makes a broker aware that your copier stopped running. That awareness has to come from your own infrastructure, because the broker will never supply it.
Frequently asked questions
What happens to my open positions if the trade copier crashes?
They stay open at the broker exactly as they are, at the same size and average price. A broker position record has no field saying which software opened it, so the broker emits no liquidation, no cancellation and no notification when the copier process exits. What stops is every future action the copier owned, including mirroring the master's exit and moving stops.
Does a dead copier mean my accounts go flat?
No. A dead copier means orphaned positions that nobody is managing, which is the opposite of flat. Risk on those accounts is now bounded only by whatever protective orders already rest at the broker, not by the master trader's discipline.
What happens if the master exits a trade while the copier is offline?
The followers stay in that trade indefinitely, because the exit signal never reaches them. The master account can close green and be done for the day while every follower still holds the losing side of the same move. This is the single largest hidden exposure in copy trading and it produces no error message anywhere.
Does a stop loss still work if the copier goes down?
It works if it rests at the broker or the exchange as a real working order, and it does not work if it exists only as copier logic. Check by looking in the follower's own broker platform, not the copier interface. If the order is not visible in the broker's order book, it disappears the moment the copier stops running.
Are trailing stops safe when the platform or copier dies?
It depends on the platform, so verify yours rather than assuming. MetaTrader 5's own help states that Trailing Stop is executed in the trading platform rather than on the server and will not work if the platform is off, while other platforms run the same feature server-side so it survives the client closing. Same feature name, opposite survival behaviour, so confirm which one you actually have before sizing risk around it.
What is reconciliation on reconnect in a trade copier?
It is the copier querying the broker for current positions and working orders per account after any reconnect, diffing that answer against its own internal ledger, and resolving differences explicitly instead of resuming blind. FIX supports it directly through Order Mass Status Request and Request for Positions, so it is a standard protocol call rather than a custom feature. It covers dropped master links, dropped follower links and silent state desync at once.
Should I run two copier instances for redundancy?
Only with a proper lock or leader election, otherwise two instances double every position. Both instances receive the same master event, both act, and the follower ends up with double the intended size and margin, which often leaves no trace in the end-of-day report because both also send the exit. For most individual traders, broker-resting stops plus fast alerting is a better investment than a second instance.
Does auto-restart fix the problem?
Auto-restart fixes exactly one failure mode, the copier process crashing on a machine that is still alive, and only if the restart reconciles first. It cannot help when the VPS itself loses power or network, because the supervisor died with it, and it does nothing when the process never exited, which covers dropped links and desynced internal state. A restart that resumes blind is worse than staying down, since it comes back confident and wrong.
How do I test my copier's failover without risking real money?
Open the smallest live position you can, then kill the copier process ungracefully with end-task or kill -9 rather than its own shutdown command. Exit the master while the copier is still dead and watch the follower stay open, then restart and see whether the first thing it does is query and report actual broker positions. Test the link failures separately by cutting the VPS network, taking only the master platform offline, and revoking one follower's credentials.
Should a watchdog automatically flatten accounts when the copier dies?
Usually no, because it converts an availability problem into a realised-loss problem. A 20-second network blip would flatten positions the strategy intended to hold, and the watchdog itself becomes a new single point of failure that must stay alive and connected. Alerting a human fast is almost always the better default.