Troubleshooting

A fresh install needs no start step — the engine ships enabled and begins ticking as soon as the addon is activated. So if nothing ticks, something is switched off or missing.

Check, in order: Enable Trading Bot on and Maintenance Mode off; the Ecosystem addon enabled; the engine cron firing. A healthy backend log shows [TRADING_BOT_ENGINE] Bot Engine started with N active bots.

On an upgrade, a deliberate "off" from an older install is carried over rather than reset. An engine you switched off previously stays off until you turn it back on here.

The Ecosystem addon is not enabled, so no process boots a matcher — and the bot engine runs only where the matcher runs. Live bots place no orders, paper bots do not tick, and stale-tick detection does not run. Even a paper bot needs the ecosystem candle feed to price.

Fix: enable Ecosystem, or disable the trading_bot extension. There is no configuration that makes this combination work.

The other three trading-bot crons — strategy ratings, daily stats, weekly cleanup — are unaffected and still run.

The engine host process died, restarted, or lost the ecosystem matching lease.

Check whether the process holding that lease is alive and whether processTradingBotEngine is still firing. Check that Maintenance Mode was not left on. A single failed engine start is recorded as a cron failure — read lastRunError rather than assuming a "completed" run did any work.

Once the engine is back it re-adopts RUNNING and PAUSED bots automatically. Bots that were flipped to ERROR in the meantime are not re-adopted; they must be started again.

Expected, and the dashboard deliberately does not render that value. The engine is a per-process singleton and an admin request is served by whichever worker picks it up, which is almost never the engine host.

Use the ticking-versus-not-responding split instead. It is computed from the database and is correct on any process.

The per-user limits are enforced, and on an install that predates that a user already over a limit hits it the first time they try.

• Too many bots — at Max Bots per User. Delete one, or raise the limit.
• Too many running — at Max Active Bots per User. Stopping one frees a slot.
• Allocation too small — below Minimum Bot Allocation.
• Maintenance Mode is on — create, start and resume are refused platform-wide.

Not the same thing: Max Concurrent Bots limits how many bots the engine holds at once, not how many a user may own. A bot holding an open position or a working order is always adopted even when the engine is over that cap.

Either Enable Live Trading is off — in which case live mode is refused for everyone while paper bots keep running — or the user's KYC level does not grant the trade_bot_live feature.

Check the KYC level before changing any setting. There is no separate "Require KYC" switch; it was removed because it never gated anything.

The messages are specific:

• "Bot has no allocated funds" — the allocation is zero. Add one from the bot's detail page.
• "Bot strategy is not configured" — strategyConfig is empty. Edit the bot and complete its parameters.
• "Bot is already running" — refresh; the status changed under you.

Open the terminal — the cockpit names the reason. The usual ones are: at the concurrency limit; out of allocation headroom; below the minimum order size; in cooldown; conditions simply not met; or a grid rung that would cross the market and is retried next tick.

None of these are errors, and none of them count towards the consecutive-error limit.

Maximum Trade Amount is a ceiling on entries. A bot whose next entry would exceed it is refused, keeps ticking, and simply opens nothing.

Exits are never refused by it, so lowering the ceiling can never trap a position. Minimum Trade Amount is the other end of the same rule, and raising it is a common reason grid bots with many small rungs go quiet.

Fix: raise the ceiling, or reduce the bot's per-trade size.

It breached its daily-loss or maximum-drawdown limit. Its working orders were cancelled and its open position closed first, then the status changed. To resume: review the strategy, adjust the limits if they were too tight, and start it again.

The opposite symptom — a bot that never reaches LIMIT_REACHED however much it loses — means it has no limits at all. Bots created before the risk defaults were applied could be saved with neither, and an empty limit can never trip. Check an older bot's risk settings before assuming the check failed. A limit set explicitly to 0 is honoured as a deliberate "no limit".

If bots hit the daily-loss limit every day at the same point, check that aggregateTradingBotDailyStats is running — the daily counters depend on it, and without it yesterday's loss carries forward.

Five consecutive tick failures, or the stale-tick watchdog flagged it after five minutes of silence. The last error message is recorded on the bot and shown on its detail page and in the admin table.

Check the price feed for its market first — a market with no candle history is the most common cause. ERROR is restartable: fix the cause and start it again.

Expected. Stopping cancels the bot's working orders; it does not liquidate inventory unless the strategy is configured to.

Use Close position in the terminal's dock — it works on a stopped bot. An admin force-stop closes positions on any process, and so does the fleet-wide emergency stop.

Read those reports carefully, because they distinguish four different states and only one of them means the work is finished:

• closed — the position is out.
• exit submitted / closing on the fill — a real market sell is on the book. It closes when it fills, which on a thin market is not immediate.
• flatten pending — the exit could not be placed yet, usually because the bot's own resting orders still hold the inventory. The platform retries in the background, normally within about thirty seconds.
• failed — nothing was placed and nothing is queued. This is the one to act on.

A position that stays open with an exit on the book for more than a few minutes means the market has no buyers at that size. The platform retires an exit that has been resting without filling and places a fresh one, so it does not sit there for ever — but a genuinely illiquid market cannot be flattened at any speed, and the honest answer is that the position waits for a bid.

By design. One rung is placed per tick, so a 25-level grid takes about 25 ticks — a little under two minutes at the default interval — to build out fully.

Rung state is read back from the bot's own orders and trades on every tick, so a rung the executor refused is retried rather than lost.

A sell rung is only considered when the bot actually holds inventory to sell.

A new grid starting in the upper half of its band works downwards to the buy rungs first — enable initialBuy if you want it to hold inventory from the start. If price has left the band downward, the bot is fully invested and there is nothing above the market to sell into.

Check the price filter. below_ma, rsi_oversold and below_price all hold the buy when the condition is not satisfied, and hold rather than pass when candle data cannot be read.

The schedule only advances when a trade actually executes, so a refused trade does not consume the interval or a maxBuys slot.

Correct. Only closed bars are evaluated, so a crossing signal fires once — on the bar where the crossing actually happened. On a 1-hour timeframe that is at most one signal per hour regardless of the 5-second tick.

Use a shorter timeframe if you want faster reaction, and expect more noise.

Check activationPercent — the trail does not arm until the position is up by that much, and until then the ordinary stop-loss is what protects it. The peak only ever ratchets upward, so the stop can never drift down.

The terminal draws the entry, the peak and the chasing stop.

The validator names the exact rule and item. See the Strategy Builder for every message it can produce and what each one means.

Two different limits. The message is about the bot's own cap, not the wallet.

Available is allocated − used, where used is open trades plus working buy orders. Raise the allocation, or wait for positions and resting orders to clear.

Wrong wallet. Bots hold from the ECO wallet; SPOT balance does not back a bot order. Marketplace purchases are the opposite — they are paid from SPOT.

Point the user at the wallet transfer screen.

Removal is limited to available capital. A bot holding an open position cannot release the part backing it.

Close the position first — Close position in the terminal works even on a stopped bot. An admin force-stop closes positions automatically and therefore never strands capital. The dashboard's strandedLive figure is the fleet-wide version of this problem.

Expected, for a moment. Placement is asynchronous — the trade row is written from the fill that actually happens, which may arrive on a later tick.

A resting limit order can sit unfilled indefinitely; it appears in the bot's orders, not its trades. The terminal draws working orders separately from filled ones.

Paper accounts are per user and per currency. A bot trading a different quote currency uses a different paper account.

Reset the account to return it to the default balance; the reset count is retained. Changing Default Paper Balance does not touch existing accounts — they keep their balance until reset.

Enable Marketplace is off. While it is off nobody can list a strategy, buy one, or claim a free one.

It does not disable strategy building. Users can still create and edit their own strategies and run bots from them, and private drafts stay editable. Use it as a deliberate lever: closing the marketplace during a review backlog leaves the trading side untouched.

A listing must be both APPROVED and PUBLIC. Check the admin queue — it may be PENDING_REVIEW or SUSPENDED.

Listings go to the queue unless Auto Approve Strategies is on. Price is never a shortcut past it: free strategies queue exactly like paid ones. A price outside the configured band is refused at listing time, so a seller may be stopped before the queue is reached at all.

Editing an approved listing's price, currency or config, or switching it to public, sends it back for re-approval.

The whole purchase runs in one transaction — if it failed, nothing was charged.

"Insufficient balance" refers to the buyer's SPOT wallet in the listing's currency. "Strategy already purchased" means a completed purchase already exists — check My Purchases. A creator cannot buy their own listing; they deploy it directly instead.

On versions before this release every paid purchase failed while free claims worked. Nobody was charged for them. If your marketplace has only ever recorded free claims, that is why — ask affected buyers to try again.

Only approved reviews are public, and only approved reviews move the rating. Clear the queue at /admin/trading-bot/reviews.

A user can only review a strategy they have a completed purchase for, and only once. A strategy with no approved reviews shows no rating rather than an old one.

The seller receives the price minus Platform Fee, which defaults to 10% — so out of the box the seller keeps 90%. There is no second percentage to set.

The rate is recorded on each sale, so changing the fee never re-prices sales that already happened. A mixed history after a change is expected.

If the platform's share cannot be routed — no Super Admin wallet configured, or the buyer is the Super Admin — the seller is credited the full price and the sale is recorded with a 0% fee. The money is never destroyed; you simply earn nothing on that sale. A run of 0% rows means your Super Admin wallet needs attention.

Free claims credit nothing but do increment the purchase count. Earnings are credited to the seller's SPOT wallet at the moment of purchase.