Live position closes are detected via two channels and reconciled between them:
WebSocket
Every supported venue's WS feed publishes position updates. When the position size flips to zero, the engine records a close with the appropriate exit reason:
- Stop-attached fill → stop loss
- Take-profit-attached fill → take profit
- Liquidation event →
liquidation - Reduce-only manual close →
manual - Signal exit (custom condition) →
signal - Trend-reversal exit → trend reversal
REST reconcile
On WebSocket reconnect, the engine pulls a snapshot of open positions and recent fills via REST. Any position the engine thought was open but the exchange shows as closed gets a close record (best-effort exit reason).
Why both
WS is fast but lossy on reconnect. REST is slow but complete. Together they catch every close even during transient outages.
What you see
The trades table shows the exit reason. Use it to audit the strategy mix: if your trend follower closes mostly via stop loss, either the stops are too tight or the trend signal is unreliable.
Pitfalls
- First reconcile after a long outage can produce a flurry of close records as the engine catches up. Time-correlate with the WS reconnect log.
- Reconcile heuristics can occasionally pick the wrong reason
when multiple exits could explain the same close. Bias is toward
the more informative reason (stop loss over
manual).