The admin console

The fleet dashboard and what each figure actually measures, the bot list and force-stop, the marketplace and review queues, and the audit trail — with the reason engine status is deliberately not shown.

4 min readUpdated 3 August 2026admin, fleet, audit, moderation

Everything an operator does lives under /admin/trading-bot. The navigation has three groups.

Screen Path Permission
Dashboard /admin/trading-bot access.trading_bot
Bots /admin/trading-bot/bot view.trading_bot.bot
Marketplace /admin/trading-bot/marketplace view.trading_bot.marketplace
Reviews /admin/trading-bot/reviews view.trading_bot.review
Audit Logs /admin/trading-bot/logs view.trading_bot.log
Settings /admin/trading-bot/settings view.trading_bot.settings

The dashboard

Fleet health, capital, performance and the moderation queues

It accepts a timeRange of 24h, 7d or 30d for the activity series and the period counters.

Fleet health

This is the block to read first, and the one people misread.

Figure Means
running Rows whose status is RUNNING
ticking Of those, the ones that have reported a tick recently
stalled Of those, the ones that have gone silent for 5 minutes
errored · paused · limitReached · stopped · draft Status counts
live · paper Mode split
attention Bots that are ERROR or stalled

The engine is a per-process singleton that runs only on the process holding the ecosystem matching lease. An admin request is served by whichever worker picks it up, which is almost never that one — so asking it would report STOPPED on a perfectly healthy install. The value is still returned by the API for back-compatibility and is deliberately not rendered.

stalled is the honest proxy. If nothing is driving the bots, every RUNNING row goes silent within five minutes and the meter says so. It is computed from the database, so it is correct on any process.

Capital

Three figures, all live bots only:

Figure Means
allocatedLive Total cap across bots in RUNNING, PAUSED or LIMIT_REACHED
usedLive What those bots actually have committed
strandedLive Allocation held by bots that are ERROR or stalled

strandedLive is the number that costs you support tickets. It is capital a user cannot release, on bots that are not trading. Chase it.

Performance

Live and paper are separated everywhere — a paper bot's day is filed as paper, so nothing counts simulated results as real money. liveWinRate is computed from settled trades (wins plus losses), because wins / totalTrades counts every still-open position as a loss.

losingLiveBots and profitableLiveBots count bots by lifetime profit, and worstPerformers names the five worst live bots so you can look at them directly.

Moderation

Pending strategies, suspended strategies, pending reviews — each with the age of the oldest item in the queue, which is the figure that tells you whether you are keeping up.

Recent activity

The last eight audit lines, with the actor resolved from the audit row's user association. Note that for an admin action the actor is the admin, not the bot's owner; the owner is preserved in the entry's metadata.

The bot list

Every bot on the install
One bot in full, with its trades, orders and recent audit entries

Filter by status, type, mode or userId, or search across bot name, symbol, description and the owner's name or email.

Force-stopping one bot

Stop a bot and unwind it, on any process

A force stop cancels the bot's working orders first, then closes its positions, then writes the status. The cancel is not optional: a working sell rung is holding the base inventory the exit needs, so a flatten attempted while it stands cannot be sized for the whole position.

Stopping alone would leave every open position open and its reservation standing — and since allocation/remove pays out allocated − used, that permanently strands the user's funds: the bot is no longer running to close the position, and the capital cannot be withdrawn.

The unwind works from the database rather than from whatever this process holds in memory, so the result does not depend on which worker served the request.

Stopping the whole fleet

Emergency stop, with a mandatory written reason

See Risk management and the kill switch for exactly what it does, in what order, and why the failure count in the response matters more than the success message.

Marketplace moderation

All listings, any status
The review queue, oldest first
Every purchase, with its fee breakdown
Marketplace revenue and counts

Four actions, all requiring edit.trading_bot.marketplace:

Action Path Requires
Approve POST …/marketplace/strategy/{id}/approve Optional notes, up to 1000 characters
Reject POST …/reject A reason, minimum 10 characters
Suspend POST …/suspend A reason
Reinstate POST …/reinstate

The pending list orders by the timestamp that moves when a strategy enters PENDING_REVIEW, so the top of the queue is genuinely the oldest submission.

A listing becomes visible in the marketplace only when it is both APPROVED and PUBLIC. Approving a listing the author left private does not publish it — that is deliberate.

Review moderation

Reviews awaiting moderation
Approve a review — this is what makes it public and lets it move the rating
Reject a review

Rejecting a review removes its contribution to the rating, both immediately and on the hourly recompute. A strategy whose reviews were all rejected shows no rating rather than its last average.

The audit trail

Every recorded action, filterable
One entry in full

Filter by action type, and scope to one user through the standard table filter — that is how the CRM user page shows a single customer's bot history.

Recorded actions include the bot lifecycle (BOT_CREATED, BOT_STARTED, BOT_STOPPED, BOT_PAUSED, BOT_RESUMED, BOT_ERROR), trading (TRADE_OPENED, TRADE_CLOSED, ORDER_PLACED, ORDER_FILLED, ORDER_CANCELLED), risk (STOP_LOSS_TRIGGERED, TAKE_PROFIT_TRIGGERED, DAILY_LIMIT_REACHED, DRAWDOWN_LIMIT_REACHED), allocation changes, marketplace events, and the admin actions ADMIN_OVERRIDE, FORCE_STOP and KILL_SWITCH_ACTIVATED.

On an admin action, userId on the audit row is the admin, and the bot's owner is preserved in the entry's metadata. An earlier build wrote the owner there, which printed the customer whose bot was stopped as the person who stopped it — on eight lines of the dashboard, with the responsible admin nowhere on the page.

Audit entries are pruned after 90 days by the weekly cleanup job, in bounded batches so the delete cannot hold row locks long enough to time out a bot's tick.

Settings

See Settings reference for all 26 keys.

Read the resolved settings
Update them — omitted fields are left unchanged

A field that is not a trading-bot setting is refused rather than stored, and the response returns the full resolved settings, not just the fields you sent.