Market order vs limit order vs stop order: which should TradingView automation use?

Why this matters

This question belongs to the reliability layer of automated trading. The goal is not merely to make a signal execute once; it is to make the result predictable, observable and safe when timing, networks, broker rules or account state change.

Automation chain

TradingView/Pine calculation
        ↓
Server-side alert
        ↓
Webhook transport
        ↓
NRUNO validation + routing
        ↓
cTrader execution
        ↓
Broker result
        ↓
Position reconciliation

Real-world scenarios

Scenario A — Immediate breakout entry

How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.

Scenario B — Pullback limit

How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.

Scenario C — Stop-entry above resistance

How to diagnose it: Record the exact symptom, preserve the relevant timestamps and IDs, identify the last successful stage, then use the next stage's log or cTrader result to locate the failure. Correct only that layer and reproduce the same case on demo.

Deep diagnostic workflow

1. Record the intended action, symbol, timeframe and exact UTC time.
2. Confirm what Pine knew at that moment—not what the historical chart shows later.
3. Inspect the server-side TradingView alert and its delivery result.
4. Record the receiver's signal ID, validation result and normalized command.
5. Record the resolved cTrader account, symbol and volume.
6. Record the exact cTrader/broker response.
7. Reconcile the final order/position state.
8. Reproduce the failure on demo after changing only one variable.

Example — EURUSD automation

A EURUSD signal may be logically correct but still produce a different live result because of bar timing, spread, symbol volume rules, a stale queued command or broker rejection. The audit trail should make it possible to state exactly where the intended action changed into the observed result.

Example — fast 1-minute strategy

For a 1-minute strategy, milliseconds can matter, but Pine timing and execution timing are separate. A signal that waits for candle confirmation has a deliberate strategy delay; that should not be reported as webhook latency. Conversely, a fast alert with a slow broker fill is not a Pine problem.

Safe implementation rules

• Define one source of truth for action, account, symbol and volume.
• Use explicit units and explicit timezones.
• Give time-sensitive signals an expiry.
• Make duplicate processing idempotent.
• Separate transport retry from broker retry.
• Never silently transform an invalid command into a different valid trade.
• Keep demo and live routing visibly separate.
• Allow exits even when an entry-time filter would block a new position, unless the strategy explicitly says otherwise.
• Preserve exact error codes for support and future Wiki improvements.

NRUNO implication

A reliable NRUNO execution trace lets a user answer: Was the signal generated? Was it delivered? Was it accepted? Which account/symbol did it resolve to? What did cTrader return? What position resulted? Support cases from these states can later become anonymized scenarios in this Wiki.

Likely follow-up questions

This page should link to the immediately adjacent problem in the user's decision path—for example repainting → bar confirmation → order timing; volume → lots/units → risk sizing; disconnect → stale signal → retry policy; multi-account → routing → wrong-account prevention.