What should I check before switching an automated strategy from demo to live?

Why this matters

Production automation must remain predictable when markets move fast, messages duplicate or reorder, accounts differ, orders partially fill, or infrastructure restarts. The goal is observable state—not merely “an alert usually opens a trade.”

End-to-end model

Pine decision
→ TradingView alert
→ authenticated webhook
→ freshness / duplicate / schema validation
→ NRUNO account + symbol routing
→ cTrader operation
→ broker result
→ position reconciliation
→ user-visible status / audit log

Real-world scenarios

Scenario A — Backtest only

Record the UTC timestamp, signal/order ID and intended action. Compare the TradingView event, webhook/NRUNO state, cTrader result and final position. The evidence should show which stage changed the intended action into the observed result; apply the documented resolution only to that stage.

Scenario B — Entries tested but exits not

Record the UTC timestamp, signal/order ID and intended action. Compare the TradingView event, webhook/NRUNO state, cTrader result and final position. The evidence should show which stage changed the intended action into the observed result; apply the documented resolution only to that stage.

Scenario C — Multi-account routing unverified

Record the UTC timestamp, signal/order ID and intended action. Compare the TradingView event, webhook/NRUNO state, cTrader result and final position. The evidence should show which stage changed the intended action into the observed result; apply the documented resolution only to that stage.

Deep diagnostic workflow

1. Freeze evidence before changing settings.
2. Establish intended action and valid time window.
3. Prove what TradingView knew at trigger time.
4. Verify message identity, authentication, freshness and ordering.
5. Verify resolved account, symbol, volume and command.
6. Read exact cTrader/broker response.
7. Reconcile requested volume with actual position state.
8. Apply the documented failure policy.
9. Reproduce on demo.

Design rules

• Explicit action/unit/account/symbol/position/expiry beats guessing.
• Current cTrader state beats assumed state.
• HTTP success, connector acceptance, cTrader acceptance and final fill are separate.
• Entry filters and risk-reducing exits need separate policies.
• Duplicate handling must be idempotent.
• Stale signals need expiry.
• Never silently convert an invalid command into a different trade.
• Exact errors belong in logs and user-facing diagnostics.

NRUNO implication

NRUNO is the execution connector, not the signal generator. It should expose validated command state, authorized routing, duplicate/stale handling, cTrader connectivity, exact execution errors and a traceable audit history. Support cases can then become anonymized Wiki scenarios.

Full demo-to-live readiness checklist

1. Realtime strategy behavior

• Verify the system in realtime, not only historical bars.
• Decide whether signals are intrabar or bar-close confirmed.
• Document repainting, HTF request.security(), calc_on_every_tick, varip, pyramiding and order-fill behavior.
• Forward-test across trend, range, spread expansion and low-liquidity conditions.

2. TradingView alerts

• Recreate alerts after material code/input/symbol/timeframe changes.
• Verify exact trigger frequency and payload.
• Test ENTRY and EXIT separately.
• Version strategy + alert.
• Test alert flooding and accidental duplicate alert instances.

3. Webhook reliability

• Test valid, malformed, duplicate and stale payloads.
• Confirm the receiver responds within TradingView's timeout.
• Confirm 5xx retries cannot duplicate trades.
• Use signal IDs and expiry for time-sensitive entries.
• Keep broker credentials out of payloads.

4. Account and symbol routing

• Prove the connector maps to the intended cTrader account.
• Make demo/live impossible to confuse.
• Test every broker-specific symbol mapping.
• Test multi-account routing independently.
• Fail closed on ambiguous routing.

5. Position sizing and protection

• Verify lots/units conversion, minimum/maximum/step and normalization.
• Verify fixed-risk sizing with realistic stop distance.
• Test FX, JPY, gold and indices separately.
• Verify SL/TP units, tick-size normalization and minimum stop constraints.
• Test spread/session/news filters.

6. Entries, exits and management

• Test BUY, SELL, CLOSE_LONG, CLOSE_SHORT and targeted close.
• Test Hedged/Netted behavior.
• Test partial closes and multiple TP targets.
• Test break-even and every trailing mode.
• Ensure risk-reducing exits remain possible when new entries are blocked.
• Test EXIT-before-ENTRY and out-of-order messages.

7. Failure handling

• Exercise BadVolume, UnknownSymbol, MarketClosed, invalid SL/TP, insufficient margin and disconnect scenarios.
• Define which transient failures may be retried.
• Never blindly retry deterministic invalid requests.
• Expire stale entries after disconnects.

8. Infrastructure

• Prove the system works with the user's PC off if that is a product claim.
• Restart/reconnect the cTrader component and reconcile positions before resuming.
• Test planned maintenance and unexpected restart.
• Verify monitoring/status/failure notifications.

9. Auditability

For one demo trade, reconstruct: TradingView condition → alert → webhook → NRUNO validation → account/symbol resolution → cTrader request → broker result → final position.

If that chain cannot be reconstructed, the system is not ready for live automation.

10. Staged live rollout

1. Demo.
2. Demo under realistic live schedule/symbols.
3. Smallest sensible live exposure.
4. One strategy/account first.
5. Observe logs and broker results.
6. Increase scope only after failure handling is proven.

Passing this checklist reduces avoidable automation/execution risk. It does not prove that a strategy is profitable.