Master Account Disconnected During Copy Trading:
A Recovery Checklist
Platform support update (September 25, 2026): TradeCopier supports MT4, MT5, cTrader, NinjaTrader 8, DXTrade, TradeLocker, MatchTrader and VertexFX. The inspected self-service menu showed MT5, TradeLocker and cTrader; ask support for setup instructions for the other platforms. Confirm your exact broker, account mode, copying direction, instrument and order actions before live use.
A master-account disconnect can interrupt observation of new source trades, but it does not tell you what already happened at a follower broker. A request may not have been sent, may have been rejected, or may have been accepted just before the connection failed. Treat its outcome as unknown until you inspect the destination account. Reconnecting without that check can leave a missing position or create duplicate exposure.
Publisher disclosure: TradeCopier publishes this guide about its own live cloud copying service. Its public activity-log page describes trade, broker-response, connection and heartbeat events, and its alerts page describes connection-change notices. Product connection choices were checked September 24, 2026. Those pages do not establish a universal queue, replay, automatic failover interval, uptime guarantee or recovery outcome for every broker route. Ask support for the current behavior of your exact connector and test it. Examples below are hypothetical teaching cases, not customer incidents or measured production results.
Identify which connection failed
| Observed failure | What it does and does not prove | First evidence to inspect |
|---|---|---|
| Source or master account unavailable | New source activity may be unobservable. Existing destination orders or positions do not disappear merely because the source connection drops. | Last source event, disconnect timestamp, source broker history and current follower positions. |
| Follower account unavailable | The copier may be unable to confirm a new destination action. A lost acknowledgement does not prove the broker rejected or ignored the request. | Copier request and response records, destination broker order/deal history and current exposure. |
| Copier or network path unavailable | Both sides may remain tradable directly at their brokers while their copy state diverges. Behavior on recovery is route-dependent. | Service status, both broker histories, route logs and support's documented recovery process. |
| Broker rejects the follower request | The rejection applies to that request, but earlier fills or other orders may remain open. | Broker code, order/deal identifiers, symbol rules, margin and account permissions. |
Do not confuse a cloud-hosted routing layer with a promise that every platform connector remains available when an account connection, broker or internet link fails. TradeCopier's platform page describes MT5, TradeLocker and cTrader as the choices observed in the inspected self-service flow. TradeCopier supports MT4 and NinjaTrader 8; confirm their current setup instructions, runtime dependencies and exact account route with support. Its cloud page says new source trades may be missed while a required connection is unavailable and warns against assuming automatic replay. Confirm the dependency for the exact route you use.
What happens to an order during a disconnect?
There are at least four distinct states: the source trade exists; the copier observed and classified it; a destination request was submitted; and the destination broker accepted, rejected or filled it. An outage can occur between any two states. In MT5, MetaQuotes says a successful OrderSend return does not alone establish execution. Its trade-transaction reference describes multiple transaction stages and says arrival priority is not guaranteed. That is why a copier log line and a broker position snapshot answer different questions.
Suppose a hypothetical master opens 0.20 lot and a follower route is configured for half size. The expected follower exposure is 0.10 lot, subject to the broker's volume rules. Immediately after a destination request, the connection times out. The safe accounting state is unresolved, not “failed” or “filled.” Inspect the follower's order and deal history and current position. If the broker filled 0.10 lot, sending a second copy can double exposure. If it rejected the request, a fresh entry may have a different price or risk. The right recovery action depends on the observed account state and your approved trading plan.
A practical recovery sequence
- Prevent additional uncertainty. If your current product configuration allows it, pause the affected copying route or stop creating new source orders until the status is understood. If an open position needs urgent protection, use your broker's direct controls and the broker's support channel. Do not assume an alert or dashboard is an emergency order-entry system.
- Save the timeline. Record the UTC time of the last known connection, first warning, source action, copier decision, request, broker response and reconnect. Export the relevant activity log and any broker statements before changing configuration.
- Inspect each broker account directly. List open and pending orders, completed deals, current positions, stop orders and quantity for the affected instruments on both master and followers. Check whether protection orders are actually held by the broker or depend on a connected platform.
- Classify every uncertain action. Mark it observed and matched, rejected with a broker code, still working, partly filled or unresolved. Use broker order/deal IDs and copier correlation IDs when available. Never treat silence as proof that no trade happened.
- Reconcile before replay. Compare intended and actual exposure, including netting-versus-hedging behavior. Use the current documented recovery process or support guidance before retrying or resuming. Amazon's idempotent API guidance explains the general duplicate-request problem; it is not evidence that a particular trading connector implements idempotency.
- Resume with a controlled test. Once all account states are known and any required correction is complete, test one permitted small or demo event and verify the broker result, not just the copied-event notification.
The account holder remains responsible for deciding whether to flatten, hedge, re-enter or leave a position. This article cannot prescribe an order for an unknown account and does not promise recovery without loss.
Test failure handling before live reliance
| Test | Record the expected behavior | Verify the observed result |
|---|---|---|
| Master disconnected before a source entry | Whether the event should be ignored, delayed or later reconciled under the documented route policy. | Source broker history, copied-event log and every follower position after reconnection. |
| Follower disconnected around a request | How the route reports an unknown acknowledgement and whether any retry is permitted. | Destination order/deal identifiers and final position before sending a new action. |
| Partial fill then reconnect | How the remaining requested quantity and close instructions are handled. | All linked deals, working orders and exposure after the connection returns. |
| Open positions at restart | Whether the current connector reconciles, skips, reopens or asks for manual review. | Before-and-after account snapshots and a support-confirmed explanation for any change. |
| Connection alert | Who receives it, through which channel and what escalation should follow. | Recorded send/receive times and whether the alert contained enough account detail. |
Do this in a permitted simulation or controlled small test, with the affected broker and account rules understood. A demo result is useful for discovering workflow gaps but cannot prove live fills, future uptime or a guaranteed recovery time.
What TradeCopier can show, and what remains to verify
TradeCopier's published activity-log documentation describes searchable trade and account events, broker responses and exports. Its alert documentation describes master/follower disconnect and reconnect notifications through configurable channels. These features can help reconstruct the timeline; they cannot substitute for checking the actual broker account. The configuration page describes route and risk settings, but no public document establishes one universal replay, queue or failover policy across all connectors. Obtain that answer for your exact platform, broker, account and direction before treating an outage runbook as validated.
Keep your test record: route and connector version, broker server, account mode, instrument, config version, event IDs, timestamps, native broker responses, account snapshots and the support answer. Re-run it after changing any of those inputs.
Quick answers
Frequently Asked Questions
Find answers to the most common questions about this topic.
If the master disconnects, do copied positions close automatically?
A source disconnect by itself does not prove that an existing broker position closed. Inspect each follower broker account directly and check whether any protective order is broker-held. The exact copier behavior is route-dependent.
Will missed trades automatically replay after reconnection?
Do not assume a replay policy. Ask TradeCopier support for the current behavior of your exact connector and test it under controlled conditions. Check broker orders, deals and positions before allowing a retry.
Can I retry a timed-out copied trade immediately?
A timeout leaves the destination outcome unresolved. First inspect the broker order and deal history and current position. Blindly retrying can produce duplicate exposure if the first request was accepted.
What is the difference between master and follower disconnection?
A master disconnect can prevent observation of new source events. A follower disconnect can prevent submission or confirmation of destination actions. In either case, existing broker orders and positions require direct verification.
Does cloud hosting guarantee no copy-trading downtime?
No. Hosted routing removes the need for a personal VPS for that layer, but the full route can still depend on account connections, broker systems, permissions and networks. The inspected app offers MT5, TradeLocker and cTrader account choices; TradeCopier supports MT4, but the inspected menu did not establish its terminal or connector runtime requirements. Check current status, logs and route-specific recovery documentation.
