Monitoring Live Strategies
Monitoring is how you keep a running strategy connected to its original thesis. A backtest can justify a small live trial, but live markets can change faster than a strategy document.
Studio should be used to watch status, exposure, fills, logs, and stop conditions after deployment.
What to monitor
| Area | Why it matters |
|---|---|
| Runner status | Confirms the independent server is online and evaluating the strategy. |
| Current exposure | Shows how much risk the strategy has opened. |
| Open orders | Reveals stale quotes, stuck orders, or unexpected maker behavior. |
| Fills | Shows whether live fills resemble the backtest assumptions. |
| Logs | Explains strategy decisions, skips, pauses, and errors. |
| Edge data freshness | Prevents strategies from trading on stale signals. |
| Market spread | Wide spreads can erase expected edge. |
| Drawdown | Live losses can invalidate the original risk plan. |
Healthy behavior
A healthy live strategy should:
- stay within max position,
- respect price bounds,
- skip entries when data is stale,
- avoid unsupported markets,
- cancel orders when conditions change,
- log why it entered or skipped,
- stop opening risk near configured close windows,
- behave similarly to the backtested version.
Reasons to pause
Pause or stop when:
- fills are materially worse than modeled,
- spreads are wider than expected,
- edge data is missing or stale,
- the market structure changed,
- the strategy reaches drawdown limits,
- the runner is repeatedly erroring,
- the user no longer believes the thesis,
- the strategy behaves differently from the approved rules.
Pausing is not failure. It is part of running automated strategies responsibly.
Comparing live to backtest
Ask:
- Are live fills near the simulated fill assumptions?
- Is trade frequency similar?
- Are skipped entries expected?
- Are fees and spreads in the expected range?
- Is drawdown inside the modeled range?
- Is edge data arriving with acceptable freshness?
If live behavior diverges, revise the strategy or stop it.
Updating monitoring rules
Monitoring rules should be explicit in the strategy or deployment settings when possible:
- alert on stale data,
- alert on runner downtime,
- alert on max exposure,
- alert on drawdown,
- alert on repeated order failures,
- alert on unexpected market selector changes.
AI agents should explain why an alert matters and what action the human should consider.
Incident response
When something looks wrong:
- pause opening new risk,
- inspect open orders and exposure,
- read recent logs,
- compare live behavior to the approved strategy,
- close or reduce risk if the user chooses,
- revise and backtest before redeploying.
Do not respond to a live issue by making the strategy more aggressive.
AI agent reporting format
A useful monitoring summary:
Runner is online. Strategy is within limits: $82 exposure against a $250 cap. Last fill was worse than modeled by about 2 cents because spread widened. Coinbase edge data is fresh. No new entries in the last 20 minutes because the strategy's spread filter blocked them. Recommendation: keep running, but do not increase size.An unsafe summary:
Everything looks good. Scaling now.Monitoring should keep the human in control.