Four webhook deliveries can still describe one gold signal

Start by naming the thing being counted

Suppose a gold dashboard receives four requests with the same signal identifier. There are four arrivals, but the economic interpretation remains open. They might be retransmissions of one message, four different updates to one setup, or messages emitted by duplicated alert configurations. Counting four trades before inspecting their identities turns a technical observation into an unsupported market claim.

My proposed audit keeps three counts: delivery attempts, distinct events and distinct setups. An event is a particular assertion, such as the creation of a setup or a later target update. A setup can therefore have several legitimate events. A delivery is merely one attempt to move an event between systems. This vocabulary lets the research archive grow without pretending that every new row represents independent evidence.

What the sender actually promises

TradingView's current help page specifies resubmission after an HTTP response in the 500–599 range, excluding 504. It describes a five-second delay and up to three resends: as many as four sends for one trigger. The separate configuration page says a request is cancelled if the receiving server takes longer than three seconds and warns that webhooks can fail to reach their destination. These are documented delivery conditions, freshly checked for this article, not a guarantee that every missing message will be recovered.

Source notes: [1] TradingView · Webhook resubmission · [2] TradingView · How to configure webhook alerts

A controlled example with no trading result

Imagine event E17 creates hypothetical setup S9. A receiver stores E17, then encounters an error before returning its response. If another copy arrives, a sound research process should recognize the previously recorded event. The delivery-attempt count becomes two, while distinct events and setups remain one. This is an invented systems example; it is not a report of any CY66 incident.

Now imagine E18 reports a later amendment to S9. Removing it just because S9 already exists would lose information. Removing every message that shares a timestamp is also unsafe: different assertions can occur within one clock interval. A useful identifier design distinguishes the original setup from each subsequent event and preserves the source payload for review.

Design for one effect, while preserving every attempt

Stripe's webhook documentation provides a useful example from another industry: it advises tracking processed event identifiers to detect duplicate receipts and states that delivery order is not guaranteed. Those are Stripe-specific documented behaviours. I use them here as a design comparison, not as a claim that TradingView has identical ordering or retry rules.

For a gold research receiver, my recommendation is to retain an append-only arrival log and make the event's state change atomic with its deduplication record. A separate lookup followed by an unprotected write can allow two simultaneous copies to pass the same check. Conflicting payloads under the same identifier should be flagged, not silently treated as interchangeable. An authenticated, schema-valid message should be durably recorded before it is acknowledged as accepted.

Source notes: [3] Stripe · Receive events in a webhook endpoint

A green delivery label answers a narrow question

A successful transport response does not establish that a chart displayed the right setup, that an entry condition occurred or that a broker executed an order. Those require their own records. Conversely, a visible error does not reveal whether the receiver performed a partial action before failing. Diagnose the application record and response body rather than assigning meaning to a colour alone.

In particular, an HTTP conflict response can have different application-specific causes. It should not be described as harmless duplicate protection without inspecting the receiver's documented reason and stored event. The same restraint applies to two apparently identical rows in a screenshot: identifiers, payloads and source configuration are needed to decide whether they are duplicates.

The practical audit before calculating anything

For one chosen interval, reconcile the sender's triggers with arrivals, accepted event identifiers, displayed setups and any independently documented execution records. Preserve mismatches as open items. Replay test messages into an isolated test environment, including repeated and reordered copies, and verify that the final research state remains consistent. A replay must never submit a real order.

Only after that reconciliation should a performance study define its eligible population. This article supplies a method, not a verified result case study. No delivery ratio, broker return or win rate has been measured here. The useful outcome is a count whose meaning survives inspection, rather than a larger number created by a noisier network.