TradingView Webhook Session Windows and Cooldowns

Layering matters because each clock protects against a different problem. Pine can avoid creating signals outside the strategy's research assumptions, but a stale or misconfigured alert can still emit. A receiver-side window rejects an otherwise valid payload outside approved days and times. The broker then applies current instrument sessions, maintenance, holiday schedules, account restrictions, and order rules. No single layer should be presented as proof that all three agree.

HexTrade documents `session` with `RTH` defined as 09:30–16:00 and `ETH` as outside that window, paired with `sessionTimezone`, plus a custom `tradeWindow` containing timezone, days, start, and end. Configure an explicit timezone rather than assuming the chart, user, server, and exchange clocks match. Test boundary minutes, overnight windows, daylight-saving transitions, holidays, and alerts delayed in transit.

A Pine session check operates on the chart's execution context and data updates. It can prevent a signal from being constructed, which keeps logs quieter and avoids unnecessary network traffic. It cannot control an old alert snapshot whose code or inputs differ from the current chart. TradingView explicitly stores a mirror image at alert creation, so changing the visible session input does not retrofit the running instance. Recreate the alert after any approved time-rule change.

A receiver rule evaluates the request when it arrives. That catches an alert delayed across a boundary and provides a centralized constraint across several scripts. It can also reject a legitimate event if the timezone, weekday, overnight convention, or daylight-saving handling differs from Pine. Treat the two configurations as code and policy: version them, write boundary examples, and test both accepted and rejected timestamps before live use.

A phrase such as “trade the morning” is not testable. A useful specification says, for example, that a route admits selected weekdays between two local wall-clock times in an explicitly named timezone, with start inclusive and end behavior verified against product documentation or testing. Do not infer those last semantics if the docs do not state them. Use dry-run examples at one minute before, at, and after each boundary to observe actual validation safely.

Overnight futures sessions need special care because the trading session date can differ from the calendar date. A Sunday-evening opening can belong economically to Monday's session, while a custom weekday array may be interpreted by local arrival date. Rather than assume, test representative timestamps and retain the results. Exchange holiday and maintenance schedules can also close trading inside an otherwise allowed custom window, so broker acceptance remains the final separate gate.

A cooldown can catch a burst from a repeated condition or two nearby alerts, but it can also interfere with valid strategy behavior. Scale-ins, rapid reversals, and an entry followed quickly by an exit all need explicit tests. The word “fill” in the documented description also deserves attention: design your test around observed product behavior rather than assuming the timer starts at receipt, validation, submission, or broker acceptance. If the exact start point is safety-critical, verify it in current documentation or support.

In-memory state creates an important operational caveat. Process restart can reset the counter, so the cooldown is not a permanent record of prior intent. It also does not collapse late TradingView retries after the interval. Pair it with source transition gating, event correlation, quantity caps, symbol allowlists, account monitoring, and a clear unknown-state policy. A layered control can reduce harm without being misrepresented as an exactly-once execution guarantee.

Signal time answers when Pine made the decision; arrival time answers when the receiver could act. Collapsing them hides delayed-entry risk. Include a non-secret time placeholder or label for correlation, then inspect TradingView alert and receiver records. Do not backdate a late event into an allowed period simply because its chart condition occurred earlier unless the execution policy explicitly permits and tests that behavior.

At a boundary, rejection can be the correct safe result. The operator should know whether to ignore, queue, or investigate it; automatically replaying at the next open changes the strategy's entry price and market regime. Similarly, a qualifying 5xx retry arrives five seconds later and may cross the window. Receiver behavior for a resend should still respect event identity and current policy without creating a second order or silently shifting the intended session.

Build a matrix with timestamp, timezone, expected Pine decision, expected receiver decision, cooldown state, expected broker availability, and actual result. Include daylight-saving dates for every timezone involved and a contract-roll period if symbols change. A table is more reliable than visually watching a clock because it exposes disagreements among chart, receiver, and exchange assumptions before money is involved.

Commission conservatively. Keep `dryRun: true` while validating fields and windows; remember it intentionally does not advance the in-memory counters. For cooldown testing, use an environment and procedure that cannot create unwanted live orders, or coordinate with product support if no safe simulation is documented. Once enabled, monitor rejected events as well as successful ones. An unexplained block is a control defect even when it prevents a trade.