Binance USD-M Futures · LIVE · Tokyo
Sign in
Dashboard
At-a-glance: is the bot alive, safe, and making money.
Wallet
Is the bot making money — and where is it coming from.
No open positions.
| Date (UTC) | Time (UTC) | Symbol | Side | Model | Qty | Price | Gross | Fees | Net | Duration | Exit | Regime |
|---|
Analysis
Are the strategies behaving as designed — performance, regime fit, history.
—
no drawdown data available
Regime breakdown — last seen (per tier)
When per-tier classification is enabled in operator_config.yaml
(regime_per_tier_enabled: true), each row shows the
regime for one tier (Majors / Large alts / Mid alts) at the
time of last classification. When per-tier is OFF, a single
global regime is shown.
| Regime | Tier | Date (UTC) | Last seen (UTC) | Recent count |
|---|
The 4 metrics this tab actually uses are defined in a slide-in panel — open it from the button above.
Commands
Whitelisted operations run on the EC2 host via SSM — fixed payloads only, never arbitrary shell.
The complete set of commands the bot accepts over Telegram — verified
against bot/engine/tg_commands.py, grouped as the bot's
own /help groups them. Some overlap the SSM runner /
Dashboard above; this is the full Telegram surface for reference.
Status
Legacy status view — service liveness, instance health, SSM agent reachability. Most of this is now folded into the Dashboard tab; this view remains as a focused secondary reference.
Logs
CloudWatch Logs from the bot service — search-driven. Turn on Tail mode for a live feed.
| Date (UTC) | Time (UTC) | Stream | Level | Message |
|---|
Audit log
Every operator-triggered write action — who, what, when. DynamoDB-backed, 90-day TTL. Config & strategy tweaks cross-link to the Backtest → Tuning log for the why.
| Date (UTC) | Time (UTC) | Actor | Action | Target | Result | Details |
|---|
Backtest
Two ways to test, each its own zone below — then active runs & storage.
Binance Vision publishes daily archives with a ~1-day lag — the latest selectable “To” is yesterday. A 3-month / 3-strategy run takes ~6h. Every run is logged to the Audit log + the Tuning log; tracked under Active runs below until it finishes.
| Strategy | BV PF | LIVE PF | Gap | Window | Verdict |
|---|
⚠ DRIFT flags when the BV-vs-LIVE PF gap exceeds 30% — the backtest no longer predicts live behaviour for that strategy.
| Sweep | Window (UTC) | Strategies | PF | WR | Trades |
|---|
A session = one continuous bot run, so it can span many days — pick a date slice to scope the replay.
Every delete + wipe needs a reason — both Audit log + Tuning log get a row per affected sweep.
Config
View & edit operator_config.yaml — grouped, searchable. Every edit needs a reason and is logged to the Tuning log + Audit log.
operator_config.yaml — raw
Edit config key
Logged to the Audit log and the Backtest Tuning log with this reason, the diff, and your user.
Alarms
What's wrong / what tripped — the bot's health & risk alarms.
| Time (UTC) | Alarm | Severity | State | Duration | Details |
|---|---|---|---|---|---|
| loading alarm history… | |||||
| Alarm | Severity | Threshold | Source | Enabled |
|---|---|---|---|---|
| loading rules… | ||||
Forensics
Browse what the bot actually recorded — the per-session decision & fill journals in S3.
| Session id | Started (UTC) | Span | Trades | Decisions | Alerts | Size | |
|---|---|---|---|---|---|---|---|
| loading sessions… | |||||||
API / Latency
The bot's connection health to Binance — latency, WebSocket state, and rate-limit headroom.
EC2 host: ap-northeast-1 (Tokyo) → Binance fapi — ~5 ms typical round-trip. Co-location is intentional for scalping.
Binance throttles by request weight and order count. Staying well under the cap is what keeps the IP off the -1003 ban list.
| Endpoint | Method | Status | Latency | Last checked (UTC) |
|---|
Cloud
The AWS infrastructure the bot runs on — instance health, networking, storage, and cost.