How to Read Webhook Execution Logs

TradingView's alert log answers whether its server created the event and what happened while delivering the HTTP request. It can show a timeout or response family, but it cannot see the downstream broker. HexTrade's docs point users to execution logs after account access and document labels such as `strategyName` and `alertName` that can improve correlation. The current interface should be treated as the authority for which exact fields are displayed; do not invent columns or statuses.

The broker account owns the final external order evidence. A receiver can accept a request that is later rejected, and a broker can accept an order that remains working rather than filled. Create a single incident row with observed facts from each source and mark missing evidence as unknown. That discipline matters most after timeouts and retries, when a plausible story can otherwise become a duplicate manual order.

HexTrade documents `strategyName`, `alertName`, `note`, and `tags` as optional labeling fields. Use a concise convention such as strategy family, reviewed version, trigger role, and a TradingView time placeholder. The label is for traceability; it is not proof of product-level idempotency. Two events can share a name, and an attacker or misconfigured script can send arbitrary labels, so route and broker evidence still need independent validation.

Account and symbol must be destination values. A chart can show a continuous future or CFD while the route uses a different broker symbol. Record both source and override when mapping is involved. For quantity, preserve the requested value and the broker's accepted or filled value separately. If a copy group fans out the master, retain a master-fill reference and create one follower outcome row rather than collapsing all accounts under a generic success.

Begin with the exact alert name and time. Confirm that the alert was active, unexpired, and based on the intended script snapshot, symbol, timeframe, and inputs. TradingView alerts run from a server-side mirror captured at creation; editing the chart afterward does not change that instance. If no event exists in the log, stay in the Pine and alert layer. Receiver and broker logs cannot explain a message that TradingView never emitted.

If an event exists, read the status literally. A 3xx points to redirect behavior; 4xx to receiver rejection; 5xx to a receiving-server failure; timeout to a response beyond three seconds; and URL, TLS, connection, or invalid-response errors to transport. TradingView documents resends only for 500–599 except 504, after five seconds, up to four total deliveries. Count those delivery attempts under one alert event rather than labeling each a new strategy signal.

HexTrade's troubleshooting docs establish common validation checks: valid JSON, lowercase `platformType`, exact `accountId`, correct ticker or mapping, and broker constraints. Compare the sanitized rendered payload with the observed record. If no receiver record exists while TradingView reports success, verify the exact private endpoint and account context before assuming data loss. If a record rejects validation, fix that first and rerun in dry mode rather than jumping to broker analysis.

If validation passes, identify whether the available record shows a broker attempt or only a planned request. `dryRun: true` intentionally sends no order, so a successful dry result must stop there. For live requests, retain any broker-facing message and reference available in the interface. Product screens evolve; this guide avoids promising particular column names. The invariant is the question sequence, not a guessed UI layout.

A successful receiver response can precede broker rejection. A broker acceptance can precede a fill by seconds, hours, or never, depending on order type and market. Partial fills change open exposure without matching either the requested size or a binary success label. Capture state transitions rather than taking one screenshot. If the product route also requested protective orders, verify those records independently; do not infer their existence from the entry payload.

For a missing broker identifier, compare a narrow time window, account, symbol, side, and quantity, but do not treat a nearby order as a match without corroboration. Manual trades can overlap automation. If the state remains unknown, pause new attempts and escalate with sanitized evidence. Replaying the webhook to see what happens destroys the clean timeline and may double the position.

Include UTC timestamps alongside local display time and timezone so daylight-saving and cross-region logs can be ordered. Preserve the alert snapshot version, source and destination symbols, group topology, and documented risk controls. Record what is absent as carefully as what is present. An incident with a sender timeout and no receiver evidence is different from one with a submitted broker order and lost final response, even if both look like “no fill” to the user.

After resolution, create a regression case. A malformed JSON incident needs a rendered-payload parser test; stale alert code needs a recreate checklist; duplicate 5xx delivery needs idempotency evidence; symbol rejection needs an allowlisted mapping test; partial follower execution needs a group pause drill. Logs add value when they change the system or runbook, not when they merely provide a story after the fact.