Working the Operations inbox — every queue and the runbook it opens
The 25 queues the header inbox counts, the SLA budget behind each amber and red badge, and which page or runbook to open when a specific queue turns red.
The inbox in the admin header answers one question — what is waiting on me — and it answers it as a number. This page is the other half: what to do once a badge turns red.
The admin panel describes the inbox as a control. This is the index that turns a red queue into the right screen and, where one exists, the right runbook.
Where the numbers come from
One endpoint feeds everything: GET /api/admin/operations/summary. It runs a
COUNT plus a MIN(createdAt) over each queue's indexed status column — no row
bodies, no joins — and returns a count, a breached, an oldestAt and an
slaHours per queue.
Two surfaces read it, both on a 60-second timer: the header inbox, and the admin dashboard's alert band and per-product operations card. Opening the inbox forces a fresh fetch, so a decision you made ten seconds ago is reflected rather than waiting for the next poll.
The SLA budgets live in backend/src/utils/sla.ts, and
frontend/config/sla.ts mirrors that file value for value. The dashboard
health card, the inbox badge and the queue's own age column are all computed from
those same numbers, so they cannot disagree.
The mirror is maintained by hand. A queue whose badge says one thing while the
Platform Health card says another is not a data problem — it is
backend/src/utils/sla.ts and frontend/config/sla.ts holding different values.
Compare the two files before you go looking for stuck rows.
The five core queues
Every install has these, whatever extensions are enabled.
| Queue | Screen | Target | Counts |
|---|---|---|---|
| Verification | /admin/crm/kyc/application |
168h (7 days) | kycApplication at PENDING |
| Withdrawals | /admin/finance/withdraw/log |
168h (7 days) | transaction WITHDRAW at PENDING |
| Deposits | /admin/finance/deposit/log |
72h (3 days) | transaction DEPOSIT at PENDING |
| Transfers | /admin/finance/transfer |
72h (3 days) | transaction OUTGOING_TRANSFER at PENDING |
| Support | /admin/crm/support |
24h | supportTicket at PENDING or OPEN |
Support has the tightest budget of the five. A ticket counts as waiting on you at
PENDING and OPEN; REPLIED means an agent has already answered, so it drops
out of the count without the ticket being closed.
Amber at half the budget, red past it
There are three states, and the boundary is a fraction of the budget rather than a fixed number of hours — a 24-hour support target and a 7-day KYC target should both mean "getting on" at the same point in their own clock.
| State | When | What it means |
|---|---|---|
| Fresh | oldest item under half the budget | Normal working stock |
| Due (amber) | oldest item at or past half the budget | Do it today |
| Breached (red) | anything past the full budget | Already late; the dashboard alert band names it |
The badge on the header control is red only when something is actually past target — otherwise it is the ordinary primary colour, because a count on its own is information, not an alarm. The panel also shows, per queue, how many of the pending items are individually breached, and a progress bar of how much of the budget the oldest item has spent, capped at 100%.
Queues you lack permission to open are hidden from your inbox, and their counts are not folded into the badge. The server returns every queue regardless of who asked; the client filters by the permission named in the table below, the same way the nav does.
So an operator whose role holds nothing but access.deposit sees a one-queue
inbox and an accurate-looking zero everywhere else. If your desk looks
implausibly quiet, check the role on Users → Roles & Permissions before you
conclude the queues are clear. See Roles and
permissions.
The whole inbox control disappears when you can open none of them.
Two more display rules worth knowing, because both are load-bearing:
- Clear queues collapse into a line of pills at the bottom rather than disappearing. "Deposits, Transfers and P2P Offers are clear" is a real answer, and a queue that vanished would leave you unable to tell checked and empty from not being counted.
- A dash (
—) instead of a number means the queue could not be read. That is not a flavour of empty. The usual cause is an extension that is enabled while its tables have not been created yet. It stays in the "needs a decision" half of the panel on purpose.
Addon queues appear only when their extension is enabled
Every addon ships its models unconditionally, so models.p2pDispute exists on an
install that has never sold P2P. The gate is the extension registry, not the
table: a queue is counted only when its extension is enabled in System →
Extension Manager (/admin/system/extension). Toggling an extension clears the
platform cache, so the inbox picks the change up on its next poll.
Twenty addon queues ship. Which of them you see depends entirely on what you have enabled.
| Queue | Screen | Extension | Target | Counts |
|---|---|---|---|---|
| P2P Disputes | /admin/p2p/dispute |
p2p |
24h | PENDING, IN_PROGRESS |
| P2P Offers | /admin/p2p/offer |
p2p |
72h | PENDING_APPROVAL |
| NFT Disputes | /admin/nft/dispute |
nft |
24h | PENDING, INVESTIGATING, ESCALATED |
| NFT Collections | /admin/nft/collection |
nft |
72h | PENDING |
| Store Orders | /admin/ecommerce/order |
ecommerce |
48h | PENDING |
| Shipments | /admin/ecommerce/shipping |
ecommerce |
48h | loadStatus PENDING |
| Merchant Payouts | /admin/gateway/payout |
gateway |
168h | PENDING |
| Refunds | /admin/gateway/payment |
gateway |
48h | PENDING |
| Merchant Applications | /admin/gateway/merchant |
gateway |
72h | PENDING |
| Forex Deposits | /admin/forex/deposit |
forex |
72h | FOREX_DEPOSIT PENDING |
| Forex Withdrawals | /admin/forex/withdraw |
forex |
168h | FOREX_WITHDRAW PENDING |
| FX Withdrawals | /admin/forex-trading/withdraw |
forex_trading |
168h | FX_TRADING_WITHDRAW PENDING |
| Token Offerings | /admin/ico/offer |
ico |
72h | PENDING |
| Staking Withdrawals | /admin/staking/position |
staking |
168h | PENDING_WITHDRAWAL |
| Referrals | /admin/affiliate/referral |
mlm |
72h | PENDING |
| Leader Applications | /admin/copy-trading/leader |
copy_trading |
72h | PENDING |
| Bot Strategies | /admin/trading-bot/marketplace |
trading_bot |
72h | PENDING_REVIEW |
| User Questions | /admin/faq/question |
knowledge_base |
72h | PENDING |
| Token Listings | /admin/dex/token |
dex |
72h | listing PENDING |
| Knowledge Gaps | /admin/ai/support/gaps |
ai_support |
72h | OPEN |
The permission each one is hidden behind:
| Queue | Permission |
|---|---|
| Verification | access.kyc.application |
| Withdrawals | access.withdraw |
| Deposits | access.deposit |
| Transfers | access.transfer |
| Support | access.support.ticket |
| P2P Disputes / Offers | access.p2p.dispute · access.p2p.offer |
| NFT Disputes / Collections | access.nft.dispute · access.nft.collection |
| Store Orders / Shipments | access.ecommerce.order · access.ecommerce.shipping |
| Merchant Payouts / Refunds / Applications | access.gateway.payout · access.gateway.payment · access.gateway.merchant |
| Forex Deposits / Withdrawals | access.forex.deposit · access.forex.withdraw |
| FX Withdrawals | access.forex_trading.withdraw |
| Token Offerings | access.ico.offer |
| Staking Withdrawals | access.staking.position |
| Referrals | access.affiliate.referral |
| Leader Applications | access.copy_trading |
| Bot Strategies | access.trading_bot.marketplace |
| User Questions | access.faq.question |
| Token Listings | access.dex.token |
| Knowledge Gaps | view.ai.support.knowledge |
Three budgets, not one per product
The addon budgets are assigned by the shape of the wait, not by which extension produced it. There are three.
Disputes — 24 hours. The tightest budget on the whole list, and deliberately tighter than a withdrawal. Escrow is held while a dispute runs, so both sides of the trade are frozen out of their own money until somebody rules. A red dispute queue is two customers who cannot transact, not a backlog.
Paid orders awaiting fulfilment — 48 hours. The customer has already been charged. Store Orders, Shipments and gateway Refunds sit here.
Approvals — 72 hours. Something waiting to be let in: a P2P offer, a merchant, a copy-trading leader, a bot strategy, an ICO offering, a referral, an NFT collection, a token listing, a public question. Nobody is out of pocket while it waits, so it is a queue rather than an incident.
Money movements keep the core money budgets instead: Merchant Payouts, Forex Withdrawals, FX Withdrawals and Staking Withdrawals all use the withdrawal budget of 168 hours, and Forex Deposits uses the deposit budget of 72.
Triage order
Work by consequence, not by count. A queue of eighty approvals is less urgent than one frozen dispute.
-
Read the dashboard alert band first.
/adminnames anything past target — the three worst queues by breach count, with a link straight into the worst one — plus a dead scheduler and critical platform health. If the band is empty, nothing is late. -
Disputes. P2P and NFT, 24-hour budget, escrow held on both sides.
-
Money out. Withdrawals, then Merchant Payouts, Forex and FX Withdrawals, then Staking Withdrawals. Filter withdrawals to
PROCESSINGas well asPENDING— a payout that started and did not finish is invisible in the inbox, because the inbox only countsPENDING. -
Money in. Deposits, Forex Deposits, Transfers. A customer who paid and was not credited will open a ticket, so clearing this also clears support.
-
Support, inside its 24 hours. Assign what you cannot answer rather than leaving it unassigned.
-
Verification. Seven days is generous, but a stalled KYC queue blocks withdrawals and trading for everyone in it.
-
Everything else — approvals, orders, listings, knowledge gaps — in whatever order the panel already sorted them, which is worst-first.
Which page a red queue opens
| Queue | Go here |
|---|---|
| Withdrawals | Working the withdrawal queue, then A withdrawal is stuck for anything at PROCESSING |
| Deposits | Working the deposit queue, then A customer paid and the balance did not move |
| Transfers | The admin panel — transfers share the deposit and withdrawal decision control; the ledger side is Customer wallets |
| Verification | KYC: levels, features and the application queue |
| Support | The admin panel — the support console, and the "All tickets" archive behind it |
| Any spot withdrawal that will not settle | The exchange provider is degraded |
| Ecosystem payouts that stopped moving | Master wallet balance and gas |
| Every queue at once, with nothing draining | The scheduler console — a dead cron process leaves the site perfectly healthy while nothing scheduled runs |
Addon queues are decided on their own product's admin screen; the href column
in the tables above is the screen, and each one opens with the rows that produced
the count.
Withdrawals reconcile, deposits expire, investments settle and prices refresh
because a scheduled job does it. When the cron app is down every one of those
stops while the website serves pages normally, and the first symptom is several
queues going red together. Check the Scheduler line on the dashboard's Platform
Health card, or pm2 list, before working a queue by hand.
Related
- The admin panel — the six areas, the decision controls behind each queue, and the daily routine.
- The health screen and what each probe means — what "degraded" was actually measuring.
- Roles and permissions — why a queue is missing from your inbox.
- The scheduler console — the jobs that drain these queues.