Automatic retries belong only on transient errors like requotes and connection timeouts, never on permanent broker rejections like invalid stops or insufficient margin. The single most important control is a retry policy that classifies the error first, then applies a bounded retry count with backoff and a circuit breaker that halts copying when failures stack up. Add broker-aware checks and a quick look at the logs before you reissue anything.
TL;DR:
- Retry policies should classify errors first, applying retries only to transient issues like requotes, timeouts, or connection drops, not permanent rejections.
- Common causes of failed copies include broker margin or stop-level violations, market unavailability, connectivity issues, and misconfigured symbol mapping.
- Fixes involve updating lot sizes, adjusting stops, verifying symbol accuracy, and ensuring terminal connections before attempting retries.
- A bounded retry approach with exponential backoff, along with account-level circuit breakers, prevents endless retry loops during systemic failures.
- Detailed logs, timestamps, and retcodes are essential for diagnosing failures, confirming successful retries, and avoiding duplicate positions.
How to classify errors: retryable vs permanent rejections
Every failed order carries a return code, and that code tells you whether retrying helps or hurts. Treating every failure the same way is the mistake that causes duplicate fills and orphaned positions, according to MQL5’s guide on order retries and circuit breakers, which separates transient retryable errors from permanent rejections and recommends a layered retry and circuit-breaker design to avoid harmful repeated submissions.
Transient errors are worth retrying because the condition causing them often clears within seconds:
- TRADE_RETCODE_REQUOTE: the price moved between quote and execution, so a fresh price usually fixes it.
- TIMEOUT: the server didn’t respond in time, often due to a slow connection rather than a rejection.
- CONNECTION: a dropped link between terminal and server, usually resolved once the connection restores.
- PRICE_CHANGED: similar to a requote, the market moved and the order needs resubmission at current price.
Permanent rejections are different. They signal a structural problem that a retry will not fix and may make worse:
- INVALID_STOPS: the stop loss or take profit violates the broker’s minimum distance, so resubmitting the same values fails every time.
- NO_MONEY: the account lacks margin for the position size, and retrying without adjusting lot size just repeats the failure.
- MARKET_CLOSED: the symbol isn’t tradable right now, and hammering the server with retries adds noise without changing the outcome.
The same MQL5 article describes an IsRetryable() check that lets a retry executor exit early on permanent codes and return a distinct outcome for partial fills, so the calling logic can route each case to the right remediation path instead of applying one blanket retry rule.
One line matters more than any other in this section: a retryable flag or explicit error classification table, checked before resubmission, is what separates safe automation from an order flood. Payment platforms outside forex have converged on the same idea. Stripe’s Smart Retries documentation describes configurable retry schedules that distinguish hard declines from retryable failures, with webhook data exposing attempt counts and next-attempt timing, a pattern worth borrowing for order retry design even outside payments.
Quick diagnosis: the checklist for the most frequent causes of failed copies
Most failed copies trace back to one of four categories. Working through them in order gets you to the right fix faster than guessing.
- Broker rejections: check for insufficient margin, a stop-level violation on the receiver symbol, or a symbol name mismatch between master and follower broker.
- Market and timing issues: confirm the symbol is actually tradable right now, watch for requotes during high-impact news, and check liquidity conditions around rollover or low-volume hours.
- Connectivity and execution problems: verify the VPS is running, the terminal is connected to the trade server, and the session hasn’t expired silently in the background.
- Copier configuration errors: look for a disabled receiver account, a lot-scaling setting that doesn’t match the account balance, or an order filter that’s blocking the symbol or order type you expect to copy.
Each category points to a different fix. A margin rejection needs a lot-size or scaling adjustment, not a retry. A disconnected terminal needs a connection check, not a configuration change. Running through this order, broker first, then market, then connectivity, then configuration, avoids wasted time chasing the wrong cause.
Pro Tip: Check the broker’s own trading-server message first; it’s the ground truth for why an order failed, and the copier log is secondary confirmation.
Step-by-step fixes for each common failure mode
Once you know the category, the fix is usually mechanical. Here’s the sequence for each of the five failure modes that come up most often.
Transient error flow:
- Capture the current bid/ask for the symbol.
- Resubmit the order at the refreshed price rather than the stale one from the original attempt.
- If it fails again, wait briefly (a few hundred milliseconds to a couple of seconds) before the next attempt, increasing the wait each time.
- Stop after a fixed number of attempts and flag the order for manual review instead of retrying indefinitely.
Invalid-stops flow:
- Pull the receiver symbol’s Stop Level and Freeze Level from its specification.
- Compare the master’s SL/TP distance against that minimum.
- Either widen the stop to clear the minimum distance or remove it and apply the stop as a separate modification once the order is open.
- Retry only after the adjustment, never with the original values.
Insufficient margin flow:
- Calculate the margin required for the intended lot size on the receiver account.
- Compare it against free margin on that account.
- Reduce the lot size, or turn on automatic lot scaling so the copier sizes positions to the account balance rather than copying a fixed lot that doesn’t fit.
- Retry only after the size is corrected.
Symbol mapping flow:
- Check the exact symbol string on both master and receiver, including any broker-specific suffix or prefix (EURUSD versus EURUSD.a, for example).
- Update the symbol map in the copier settings so the receiver order uses the correct local name.
- Send a small test order to confirm the mapping resolves before relying on it for live trades.
Orphaned or duplicate positions:
- Pull open positions on both master and follower accounts and compare ticket counts and volumes.
- Close any follower position that has no matching master position, after confirming it wasn’t intentionally left open.
- Flatten mismatched positions before re-enabling copying on that account, so the next copy cycle starts from a clean state.
- Document the mismatch and its cause before resuming automated copying, so the same error doesn’t repeat unnoticed.
Configure safe automatic retries: retry limits, backoff, and circuit breaker patterns
A retry policy without limits isn’t automation, it’s a slow-motion accident. The goal is a bounded number of attempts, spaced out enough to let transient conditions clear, with a hard stop that kicks in when failures start stacking up across orders rather than just one.
- Retry attempts: cap each order at a small, fixed number of tries rather than retrying indefinitely.
- Exponential backoff with jitter: increase the wait between attempts each time, and add a small random variation so multiple orders don’t all retry at the exact same moment.
- Max total retry window: set an overall time limit per order so a stuck retry loop doesn’t run for minutes while the market moves away from the original signal.
- Circuit breaker threshold: track consecutive failures across the account, not just per order, and open the breaker (stop all automatic submissions) once that threshold is hit.
- Cooldown period: once open, the breaker should stay open for a fixed interval before attempting anything else.
- Half-open probes: after cooldown, allow a small number of controlled submissions rather than resuming full volume immediately.
The MQL5 article on retries and circuit breakers describes exactly this layering: a CRetryExecutor for per-submission retries, a CCircuitBreaker for global failure tracking, and a CExecutionGateway that combines both. It recommends the half-open state allow only a small number of probe submissions and require a short run of successes, something like two consecutive successful probes, before the breaker fully closes and normal operation resumes. A single failed probe should re-open the breaker and extend the cooldown rather than reset it to the original length.
This two-layer design (per-order retry plus account-level circuit breaker) matters because a single bad symbol or a brief server hiccup shouldn’t be treated the same as a systemic outage. Per-order retries handle the first case. The circuit breaker catches the second, pausing copying across the board until conditions stabilize. A broader look at automated trading risk controls covers similar halt conditions and retry limits for algorithmic systems generally, and the logic transfers directly to trade copying.
Pro Tip: Log every circuit breaker state change (closed, open, half-open) with a timestamp; it’s the fastest way to explain a gap in copied trades after the fact.
Logs, alerts, and verification: what to inspect to confirm whether retries succeeded or created duplicates
The log is where you find out whether a retry actually worked or just added a duplicate position. MT4 and MT5 both record OrderSend results in the terminal’s Experts and Journal tabs, and a copier adds its own log layer on top.
- Retcode: the numeric result of the submission attempt, the first thing to check against your retryable/permanent classification.
- Order ticket: the unique identifier assigned to a successful order, used to confirm the follower order actually matches a specific master order.
- Volume: the lot size that was actually filled, which should match the scaled lot size the copier intended to send.
- Timestamp: the exact time of submission and fill, used to correlate master and follower orders and spot duplicates.
To check for duplicates, line up the master ticket’s timestamp and volume against the follower ticket’s timestamp and volume. A duplicate usually shows up as two follower tickets with nearly identical timestamps and matching volume against a single master order. The guide to monitoring copier logs on MT4, MT5, and DXTrade walks through where each platform stores this data and how to read it without digging through raw terminal files.
Set up basic alerting around three conditions: a heartbeat check that flags when the copier stops reporting activity, a reconnect alert when the terminal drops and restores its connection, and a failure-rate threshold that notifies you when a percentage of recent orders fail rather than waiting for a single error to surface. When you need to manually force a retry after fixing the underlying cause, use the copier’s manual “process now” function on the specific order rather than restarting the whole terminal, then check the log immediately afterward to confirm a single clean fill.
Broker-specific checks: stop levels, partial fills, pending-order rules, and account types
Brokers don’t all enforce the same constraints, and assuming they do is a common source of silent rejections. MQL5’s analysis of Stop Level effects on SL/TP copying documents how different brokers enforce different Stop Level and Freeze Level minimums, causing SL/TP modification rejections that look like copier bugs but are actually broker-side constraints.
- Stop Level and Freeze Level: pull these values from the receiver symbol’s specification and enforce them as a minimum distance before sending any SL/TP, rather than copying the master’s exact values blindly.
- Pending versus market orders: when the receiver broker has stricter entry-price rules for pending orders, convert to a market order on trigger instead of forcing a pending order that gets rejected.
- Partial fills and lot rounding: some brokers fill less than the requested volume or round lot sizes to their own step size, which can leave the follower position slightly mismatched from the master.
- Account type differences: netting accounts handle multiple positions on the same symbol differently than hedging accounts, and FIFO rules on netting accounts can block an order that would execute cleanly on a hedging account.
A Stop Level or Freeze Level mismatch between master and receiver broker is one of the most common causes of SL/TP rejections in cross-broker copying, according to MQL5’s testing on the topic. The same source recommends checking symbol specifications on each receiver broker individually rather than assuming uniform behavior across brokers.
Before any live deployment, run the same symbol, lot size, and SL/TP distance through a demo receiver account first. If the demo account rejects it, the live account will too, and you’ve caught the problem without risking a real position. For deeper coverage of how differing stop levels create the appearance of a frozen or delayed follower order, see the guide on trade copiers waiting for SL/TP to be hit.
Operational best practices to reduce failures and the need for retries
The best retry policy is the one you rarely need, because most failures are preventable with a few operational habits.
- VPS uptime: run the copier on a VPS with consistent uptime rather than a home PC that sleeps, loses power, or restarts for updates mid-session.
- Timezone-aligned maintenance: schedule VPS or terminal restarts during the symbol’s known low-activity window, not during active trading hours.
- Pre-deployment checklist: run a demo test covering symbol mapping, Stop Level verification, and lot-scaling behavior before connecting a live receiver account.
- Daily reconciliation: after each session close, compare open positions between master and followers to catch an orphaned or partially copied order before it compounds into a bigger problem the next day.
- Incident runbook: keep a single document listing common retcodes, their fix, and where to find the relevant log, so troubleshooting doesn’t start from scratch every time.
Pro Tip: Run your reconciliation check at the same time every day right after close; a routine catches small mismatches before they turn into a pile of orphaned positions a week later.
Field-tested checklist and example log excerpts from the Local Trade Copier author
A repeatable troubleshooting sequence beats improvising each time a copy fails. This is the order Rimantas, who has worked on Local Trade Copier’s diagnostics since the product’s early years, recommends working through:
- Pull the full log for the failed order, not just the error line, so you can see what happened immediately before and after.
- Identify the exact retcode and check it against your retryable versus permanent classification.
- Confirm the symbol mapping between master and receiver matches exactly, suffix and prefix included.
- Check free margin against the required margin for the intended lot size.
- Decide, based on the above, whether to let the retry logic handle it automatically or flag it for manual action.
A log entry showing retcode=10004 (REQUOTE) followed by a successful fill on the second attempt confirms the retry logic is working as intended. A log entry repeating retcode=10019 (NO_MONEY) across several attempts means the retry should have stopped after the first failure and routed to a margin check instead, not kept firing. For a specific example of a recurring client-side error and its fix, see the walkthrough of error 133 on MT4 client accounts, and for a broader first-pass diagnostic flow when copying stops entirely, the guide on what to do when Local Trade Copier isn’t copying trades covers the same checklist in more detail.
A retry policy that can’t tell a requote from a margin rejection isn’t protecting the account, it’s just failing more quietly.
What the data actually supports about retry automation
Most advice on this topic treats “retry” as a single setting to switch on, a number of attempts and a delay, nothing more. That framing undersells the actual risk. The real failure mode isn’t too few retries, it’s retries applied to an error that was never going to succeed in the first place, which wastes time at best and creates a duplicate position at worst.
The conventional wisdom skips the circuit breaker almost entirely, treating each order as an isolated event. But a broker outage or a margin shortfall rarely affects just one order, and a per-order retry loop with no account-level awareness will keep hammering a system that’s already in trouble. The fix readers should prioritize first isn’t a bigger retry count or a cleverer backoff curve. It’s building the classification step: knowing, before any retry fires, whether the error is the kind that clears on its own. Everything else, backoff, jitter, cooldowns, is secondary to getting that one decision right.
— Rimantas
Local Trade Copier: features built around safer retries
This type of trade copier software typically runs locally on a Windows machine or VPS without cloud routing, so logs for retry diagnosis are centralized rather than distributed across third-party servers. Such software often includes detailed per-order logging, configurable retry behavior, and multiple lot size and risk management options, potentially including automatic lot scaling per account balance to address margin-related rejections. It generally supports copying trades across platforms like MT4, MT5, and DXTrade from a single master account to multiple receiver accounts.
| Feature | What it addresses |
|---|---|
| Local execution with low latency | Reduces the timing gap that causes requote-driven retries |
| Automatic lot scaling per account balance | Reduces margin-related rejections without manual lot adjustment |
| Cross-platform copying (MT4, MT5, DXTrade) | Keeps retry and log behavior consistent across broker platforms |
| Detailed local logs | Gives the retcode and timestamp data needed to confirm a retry succeeded cleanly |
This type of software functions solely as trade replication software, copying existing orders from a master account to connected receivers, without any market logic, strategy layer, or influence on trading outcomes. Past results do not guarantee future performance.
- Free trials are often offered before committing to a subscription plan.
- Review the pricing page for the PERSONAL Plan at 29 € per month, the MANAGER Plan at 89 € per month, or the VIP Plan at 199 € per month, with annual billing available at 290 €, 890 €, and 1990 € respectively.
- Check the installation guide if you’re setting up on a VPS for the first time.
If you’re troubleshooting failed copies right now, the pricing page is the fastest way to see which plan fits your number of receiver accounts.
FAQ
What is the difference between a retryable and a permanent order error?
A retryable error, like a requote or a connection timeout, stems from a temporary condition that often clears within seconds, so resubmitting the order can succeed. A permanent error, like invalid stops or insufficient margin, comes from a structural mismatch that a retry alone won’t fix, according to MQL5’s error classification guide.
How many times should a copier retry a failed order?
There’s no universal number, but a small, fixed cap paired with exponential backoff is the pattern recommended in MQL5’s retry and circuit-breaker design, rather than retrying indefinitely. Pair that per-order limit with an account-level circuit breaker that halts all automatic retries after repeated consecutive failures.
Why does my trade copier keep rejecting stop loss or take profit values?
This usually means the receiver broker’s Stop Level or Freeze Level requires a wider minimum distance than the master’s SL/TP, a common cross-broker issue documented in MQL5’s analysis of Stop Level effects. Check the receiver symbol’s specification and widen the stop distance before resubmitting.
How do I prevent duplicate positions when retrying a failed copy?
Compare order tickets, volumes, and timestamps between master and follower accounts before and after a retry to confirm only one follower order matches each master order. A circuit breaker that pauses automatic retries during repeated failures, as described in MQL5’s circuit breaker pattern, also reduces the chance of a retry loop creating extra positions.
Does Local Trade Copier automatically retry failed trades?
Local Trade Copier includes configurable retry behavior and detailed logging so you can see why an order failed and whether a retry succeeded, alongside automatic lot scaling to address margin-related rejections. It is trade replication software only, copying existing orders from a master account with no influence on trading outcomes, and past results do not guarantee future performance.
Sources
Recommended
- What to do when Local Trade Copier does not copy trades
- Stop Duplicate MT4 Trades in 5 Minutes for Users and EA Authors
- Rebooting Local Trade Copier client and server with open positions
- Local Trade Copier and error 133 on the MT4 Client Account
