Troubleshooting
The reports this addon actually generates — nothing is copying, one follower stopped mid-session, funds are stuck, statistics read zero, binary copies are skipped — and how to tell which layer is at fault.
Most copy-trading tickets are one of six reports. Each has a small number of causes, and almost all of them are visible without touching the database.
Nothing is being copied at all
Work down this list in order. Every gate below is silent by design — the leader's own order is never blocked, so there is no error anywhere to find.
copyTradingEnabled on the platform tab, and copyTradingMaintenanceMode off.
With the master switch off, the backstop logs "Copy trading is disabled, skipping"
on every tick and reports the run as completed.
copyTradingEnableSpot for spot, copyTradingEnableBinary plus platform-wide
binary trading for binary. Spot copying additionally checks that the Ecosystem
extension is enabled, not merely installed — turning the extension off stops
replication cleanly rather than writing copies for orders that were never placed.
A PENDING, SUSPENDED or REJECTED leader is skipped silently. Check
/admin/copy-trading/leader.
A BINARY-only leader's spot orders are never replicated, and vice versa. This is
easy to miss on a leader who was approved for one class and has since started
trading the other.
Only markets on the leader's own list are replicated. A market that was disabled with the toggle stops copying without removing anyone's allocation.
No followers, no work — the hook returns before writing anything. A leader whose followers were all paused by a suspension counts as none.
The in-memory queue is filled by the hook on the process that serves the leader's order and drained by that same process. Look for this line in that process's startup log:
[CRON] Copy trading queue initializedIf it is missing, copies still happen — but only via the database backstop, which picks trades up two minutes after they were placed. "Copies arrive, but always about two minutes late" is the exact signature of this fault.
One follower is not copying while others are
This is almost always the follower's own configuration, and the reason is recorded.
| Symptom | Cause |
|---|---|
| Nothing at all on one market | No allocation on that (symbol, class), or the allocation was deactivated when the leader removed the market |
| Only buys are copied, never sells | The spot allocation has quote budget but no base budget. A SELL copy spends base |
| Only sells are copied, never buys | The mirror image — no quote budget |
| Copying stopped partway through the day | A daily limit. See below |
| Every copy skipped as "amount below minimum" | The computed size is under the ecosystem market's own minimum order size — the allocation is too small for this leader's trade sizes, or FIXED_RATIO is set very low |
| "Leader balance unknown" | PROPORTIONAL mode and the leader's ECO balance in the quote currency reads as zero. Switch that follower to FIXED_AMOUNT or FIXED_RATIO, or ask the leader why their quote wallet is empty |
| "Fixed amount not configured" | FIXED_AMOUNT mode with no amount set |
A follower stopped copying after about 20 trades today
The copy engine reads the maximum number of copies per day from
copyTradingMaxDailyLossDefault — the risk-tab setting labelled Default Max
Daily Loss, which ships at 20. Once a follower has 20 trades on the day they are
refused with "Daily trade limit reached", on both the live path and the backstop.
Raise that setting if you intend high-frequency leaders to be copyable. Nothing else changes it.
The separate, per-subscription maxDailyLoss is what pauses a follower for losses.
It is compared against the day's realised loss converted to USDT, not a
percentage, and the check runs once a minute from UTC midnight. When it trips, the
subscription goes to PAUSED, the follower is notified with the figure, and an
audit entry records it.
That pause lifts on the next UTC day — but only if the most recent pause or resume
event on the subscription is itself a daily-loss pause from a previous day, and
only if their leader is still ACTIVE. A follower who paused deliberately, or
whose leader was suspended, is never restarted automatically.
Funds look stuck in the copy-trading wallet
First, distinguish the two things that look identical from the outside.
Committed to an open order is normal. The allocation shows a used amount, the
wallet shows an inOrder balance, and both release when the order fills or is
cancelled. Nothing is wrong.
Stranded means the copy is gone but the hold is not. Three mechanisms exist to clean that up, in increasing order of patience:
-
The reconciler, every five minutes. It looks at live follower copies older than two minutes whose underlying order is cancelled or missing, tears them down, and releases the hold. It is release-only and safe to re-run.
-
Force-stopping the subscription from
/admin/copy-trading/follower, which runs the full teardown and returns everything unspent to ECO or SPOT. -
Deleting the leader with
refundFollowersleft on, which refunds every follower's unused allocation. Repeating it cannot double-refund.
If the money is behind a leader who cannot trade — suspended, rejected, still pending, removed — the admin dashboard reports it as stranded with the reason named, and the leader table on that page ranks leaders by how much idle capital they hold. Start there rather than in the wallet table.
Spot allocations return to ECO. Binary stake budgets return to SPOT. A follower reporting "my refund never arrived" is often looking at the wrong wallet.
Statistics read zero or look wrong
Leader and follower statistics are calculated on demand from the trades table and cached in Redis, rather than stored. There is no counter to be out of date.
| Symptom | Cause |
|---|---|
| Everything reads zero | Redis unreachable, or genuinely no CLOSED trades with recorded profit |
| One leader looks stale | Cached. Use Recalculate on the leader detail page |
| Daily stats missing for a day | updateCopyTradingLeaderDailyStats did not run. Check its lastRunError at /admin/system/cron |
| Return percentage looks enormous on an old SELL copy | A historic defect: the percentage on closed SELL copies was divided by the base quantity rather than the money committed. Fixed for copies closed since, and not recalculated for rows already stored |
Aggregated figures are converted to USDT. When a conversion fails the raw value is used and a warning is logged, so a leader trading an exotic quote asset can show a total that is a sum of unconverted amounts.
Binary copies are never placed
Binary has more gates than spot, and each refuses with its own reason.
| Reason in the log | Fix |
|---|---|
| Binary copy trading is currently disabled | copyTradingEnableBinary |
| Binary trading is currently disabled on this platform | The core binary setting — copied orders would be rejected by the binary engine anyway |
| Invalid or inactive binary market | The symbol is not an active market at /admin/finance/binary/market |
| Leader order has no payout rate | Correct behaviour. A copy must be the same contract as the leader's, and the engine no longer invents a payout percentage. Core stopped producing such orders |
| Too close to expiry / order too stale | The fairness window: at least 15 seconds must remain before expiry, and the leader's order must be under 90 seconds old |
| Stake calculates to zero | The budget is exhausted, or copyTradingBinaryMaxStake is set very low |
If a leader cannot declare the same symbol for both spot and binary, the schema self-heal has not run. Boot the backend once with database sync enabled — see Install.
A leader trade is parked as REPLICATION_FAILED
Three ways a leader trade reaches that state, and only one of them is transient:
- Five failed attempts. At least one follower copy genuinely failed on five consecutive backstop passes. The attempt count is written onto the row.
- No leader order id. The trade cannot be deduplicated or torn down, so it is refused rather than replicated.
- The leader no longer offers that class. The row is parked rather than left pending, so it does not starve every later batch.
Nothing revisits that state. Read the failure panel on the admin dashboard, which shows the five most recent failures with the engine's own message, and decide whether the underlying cause has been fixed before you do anything by hand.
Stop-loss looks broken on one market
Stop levels are measured against real, order-backed liquidity only. On an AI-managed market whose book is largely display levels, there is nothing to measure against, and a warning naming the market points at Admin → AI Market Maker → Markets → (market) → Real Liquidity %.
The remedy is a market configuration change. No copy-trading setting will fix it.
Two other reasons a stop does not fire:
- The entry never filled. Only copies with an actual filled quantity are considered, deliberately — a stop must not act on a position the follower never held.
- The exit order has not filled yet. A triggered trade reads
CLOSINGuntil its real opposite order fills. Closing has not been instantaneous since the settlement path was made to trade rather than to credit.
Scheduled tasks show no status
All eight jobs report to Admin → System → System Monitoring → Scheduled Tasks
under the copy_trading category. If one shows no status, no logs and no results,
that is indistinguishable from a job that never runs — check lastRunError there
first, before assuming a data problem.
The two whose absence is most expensive:
processPendingCopyTrades— without it, any trade the live queue drops is never picked up, and there is no visible symptom because live copying still works.resetCopyTradingDailyLimits— without it, followers paused by a daily-loss limit stay paused indefinitely.