Last Updated: 2026-10-27
A chart condition, a delivered message and an exchange fill are three different records. This guide describes how to trace them and test failure cases without a trading connection. It does not supply a live receiver, establish a profitable strategy or recommend moving from a test to real money.
Keep five records separate
Scroll sideways to see every column. Keyboard: focus the table region and use the arrow keys.
| Stage | Record to preserve | What success does not prove |
|---|---|---|
| Chart rule | Venue, instrument, timeframe, rule version and input values | Predictive value of the rule |
| Alert | Condition, firing time, frequency and enabled/expiry state | Receipt by the next system |
| Delivery | Response status and delivery attempt | Acceptance of a valid order |
| Receiver | Validation result, event ID and processing state | Exchange acceptance or a fill |
| Exchange | Client/order IDs, acknowledgements, fills and position reconciliation | Profitability or correctness of the original signal |
Broker integration in a chart and a webhook to a separate receiver are distinct paths. Check which is connected before testing. A visible market chart does not establish an available trading connection, and an alert-to-receiver test does not exercise a broker integration.
Define the observation first
For a close-based rule, state that it uses a completed bar. An intrabar crossing can disappear before the close; that does not mean the earlier observation never happened. It means the live rule differs from the completed-bar rule being reviewed later.
Bar-close timing does not fix every form of repainting. Higher-timeframe requests, future information, delayed pivot confirmation and revised data need separate inspection. Preserve live observations and compare them with later chart values. A sample of twenty unchanged signals can reveal some problems, but cannot prove a script never repaints. See the Pine alert documentation for the distinction between script conditions, running alerts and their saved settings.
Version the symbol, inputs, rule and receiver configuration together. If one changes, record whether existing alerts need recreation; do not assume editing the visible chart changes a running alert.
Inspect a message that cannot trade
The official webhook guide describes POST delivery, JSON content type only for valid JSON, supported ports and a three-second receiver timeout. It requires two-factor authentication and cautions against sending credentials in the body. Check current plan entitlement separately in the plan review; this guide does not duplicate a subscription table.
Use a test receiver with no exchange keys or order submission capability. This synthetic record is a local test fixture, not a vendor payload or a ready-to-paste order:
{
"event_id": "fixture-001",
"mode": "observe_only",
"rule_version": "close-above-level-v1",
"instrument": "EXAMPLE:ASSETUSD",
"bar_open_utc": "2026-10-27T10:00:00Z",
"fired_utc": "2026-10-27T11:00:00Z",
"received_utc": "2026-10-27T11:00:02Z",
"observed_price": 104
}Here the bar is an hour old when the alert fires; delivery takes two seconds between firing and receipt, assuming synchronized clocks. Subtracting bar opening time from receipt would incorrectly call one hour and two seconds network latency. An actual fill needs its own timestamp, quantity and price. Do not infer it from the observation field.
The event ID is illustrative. In an implementation, define how a stable identifier is generated for one intended action and stored durably. A new identifier on every retry defeats duplicate protection. A shared identifier across unrelated actions can incorrectly suppress valid events.
Retries make duplicate handling necessary
TradingView's resubmission policy documents up to three resends, five seconds apart, for receiver responses from 500 through 599 except 504: at most four sends for one trigger. This is a conditional policy, not a guarantee that every lost message is recovered. The older claim that no retry ever occurs was incorrect.
A receiver can accept an order and then lose its response. Retrying blindly may create a second order. Mark the outcome uncertain, reconcile using stable identifiers and query the actual order state before deciding whether another submission is needed. "HTTP 200" can mean only that the receiver stored a message; define that contract explicitly.
Test the failure states deliberately
Scroll sideways to see every column. Keyboard: focus the table region and use the arrow keys.
| Synthetic input or event | Required observation before calling the test successful |
|---|---|
| Same event twice, including concurrently | One intended action recorded; duplicate outcome visible |
| Malformed JSON or missing required field | Rejected with a reason; no order intent created |
| Message older than the rule's declared validity window | Marked stale; no fresh action inferred |
| Unknown instrument or disabled rule | Rejected against an explicit allowed configuration |
| Receiver failure after persistence | Recovery finds the existing record rather than adding another |
| Exchange timeout after submission | Uncertain state retained until reconciliation, not assumed rejected |
| Alert fires but no delivery record exists | Missing delivery reported separately from no signal |
These are acceptance criteria, not a claim that any named platform already implements them. For a rented receiver, request its current payload schema, simulation availability, expiry and deduplication behavior, supported account modes and error logs. A test mode at one provider does not establish the same mode at another.
Make cost units explicit
Synthetic costs: $40 per month on a $500 reference balance is 8% of that balance each month, or $480 and 96% over twelve months without compounding. That is a tooling expense comparison, not a required or achievable market return forecast.
For twenty round trips per week at $100 notional per leg and a hypothetical 0.1% fee per filled leg: weekly filled turnover is $4,000, weekly fees $4 and annual fees $208 over fifty-two identical weeks. Divide by the chosen capital denominator separately. If a turnover figure already includes both legs, do not double it again. Add actual slippage, spread treatment, funding and subscription costs without counting the same cost twice.
A limit order bounds its execution price but may not fill. A market order can fill away from the observed price. Measure your own delay and fill distribution; this article has no evidence for a universal two-to-ten-second latency or a fixed profitable timeframe.
Permission and monitoring boundaries
Keep exchange keys and login credentials out of alert messages, logs and screenshots. Review the actual authority of any connection. Disabling withdrawals reduces one route of loss; malicious trading can still lose funds. An IP allowlist may identify an infrastructure source without identifying your individual alert, so it is not a complete authorization design.
Compare alert, receiver and exchange records using their distinct states. Watch for expired or disabled alerts, missing observations and receiver failures; an empty log alone does not prove the market was quiet. Match monitoring frequency to the workflow's actual tolerance rather than assuming a weekly check is always sufficient.
Successful routing proves routing. Keep the simulation isolated until separate strategy, execution and operational decisions have evidence; there is no automatic next step to live trading. For alternative architectures, see how to automate crypto trading.
Educational engineering analysis, not financial advice or a return promise. Trading can lose capital. The site may earn referral commissions; this guide makes no personal-use claim or untested provider recommendation.