TradingView Stale Webhook: Timestamps vs Order Expiry

A TradingView stale webhook is an alert that arrives after the signal is no longer timely for your trading plan. A timestamp helps identify the delay, but it does not automatically reject an old message. Order expiry controls how long a submitted order can remain working, which is a separate question.

For traders using TradingView, PickMyTrade and Tradovate, this distinction matters. A late alert could create a new order; an order submitted promptly could remain pending afterward. This guide explains the timestamps, the checks to make, and what to confirm before relying on a freshness filter.

Key takeaways

• TradingView’s {{time}} identifies the triggering bar; {{timenow}} identifies the alert firing time.
• PickMyTrade’s documented date field carries a timestamp; the reviewed documentation does not establish a configurable maximum alert age.
• GTD governs a submitted order’s duration, not automatically the incoming webhook’s age.
• Check TradingView, PickMyTrade and broker records before replaying a signal.
• Test time-based controls in demo and confirm the broker’s actual order status.

What is a TradingView stale webhook?

A stale webhook is a message received too late to be useful under your trading rules. One strategy may consider a signal 20 seconds old unacceptable; another may tolerate longer. The threshold depends on the setup and is not a universal PickMyTrade setting established by the sources reviewed.

An alert may appear old because its chart bar began earlier, the condition waited for a bar close, delivery was delayed, or the order stayed pending after receipt. These are different events. Start by identifying what each timestamp represents.

TradingView sends webhooks as HTTP requests when alerts fire. Its webhook documentation says delivery can occasionally fail and provides a webhook status in the alert log. A successful delivery status alone does not prove that a broker accepted or filled an order.

The clocks in an automated trade

Follow one event through the route instead of comparing a chart marker directly with a broker fill.

Compare records using the same time zone and note their precision. If a time is missing, ask support for the relevant logs instead of assuming the value.

TradingView {{time}} vs {{timenow}}

TradingView defines {{time}} as the time of the bar on which an alert triggers. Its {{timenow}} placeholder represents the firing time in UTC, rounded to the nearest second. See the TradingView placeholder reference.

Imagine a five-minute bar beginning at 10:00:00 UTC. A condition fires at 10:04:30 UTC and the receiver records the request at 10:04:32 UTC. The bar is four minutes and 30 seconds old when the alert fires, but the observed firing-to-receipt difference is about two seconds, subject to clock accuracy and timestamp precision.

If the strategy waits for a bar to close, the time between bar start and alert firing may reflect the strategy’s rules rather than network latency. A historical chart marker may also represent a different event or change after recalculation. Preserve the real-time alert record for comparison.

Does PickMyTrade’s date field reject old alerts?

The PickMyTrade JSON reference shows a date field populated with {{timenow}} and describes it as a timestamp. The reviewed documentation does not specify a configurable maximum message age, rejection threshold, or handling of missing and future timestamps.

The field may help identify when an event fired, but do not assume it enforces your desired freshness rule. This finding also does not prove that no such control exists in another version or configuration. Confirm behavior for your account and connector with PickMyTrade support.

For example, if your rule is “reject an entry more than 30 seconds after firing,” ask whether age is checked before order submission, what format is accepted, and how rejection appears in the Alert Log. Thirty seconds is a hypothetical requirement, not a documented default.

Check how the alert message is created

The alert method matters. TradingView supports placeholders in suitable alert messages and alertcondition() contexts, but its Pine Script documentation says messages produced by alert() do not process placeholders in the same way. A literal {{timenow}} in a received message is not a timestamp.

Use the method documented for the indicator or strategy, then inspect a saved demo alert. An alert() message may need the script to construct its dynamic time value. Confirm the format with support and remove tokens and credentials from any message you share.

Why GTD and signal freshness are different

Good Till Date, or GTD, describes an order’s intended lifetime. An incoming signal-age rule decides whether to act on a message based on its age. The first applies to an order after submission; the second applies before an order is sent.

Suppose an alert fires at 10:00:00 UTC and reaches the receiver at 10:01:30. If the receiver accepts it and submits an order with a one-minute lifetime, that lifetime does not undo the 90 seconds before receipt. The order could be new even though the signal is already too old for the trader’s plan.

The opposite can also happen: an alert arrives promptly and a limit order is accepted, but remains unfilled. Depending on broker rules, it can remain working until filled, canceled or expired. Review the broker’s order status rather than inferring it from the age of the alert.

Tradovate GTD notice: As checked on October 27, 2026, PickMyTrade’s limit-order guide warns that GTD expiration, including gtd_in_second, may not work correctly and orders may remain active beyond the intended time. Confirm the current issue status, monitor working orders and cancel unwanted orders as appropriate.

How to investigate a TradingView stale webhook

Use the same event and account throughout your investigation. Preserve records before changing alerts or submitting another order.

1. Identify the event. Record symbol, side, quantity, alert name, timeframe and destination account. Note whether it was an indicator alert, strategy order-fill alert or alert() event.
2. Review TradingView. Note the firing time, message and webhook status. Identify the chart time zone and alert frequency before comparing the firing time with the bar time.
3. Review PickMyTrade. Check the Alert Log for the matching event and any error. Record the processing time if displayed. If there is no match, support may need to inspect receiver logs.
4. Check broker orders and positions. Record the order ID, status and times. An order can be partially filled, leaving both a position and a working remainder.
5. Compare each interval. Separate bar start to alert, alert to receiver, and order submission to fill. Consider time-zone conversion, clock skew and timestamps rounded to seconds.
6. Review alert settings. Confirm the correct condition, alert frequency and script settings. If strategy inputs changed after alert creation, recreate the alert as needed and verify it in demo. If PickMyTrade settings changed, follow its saved alerts guidance to update the generated message.

If TradingView shows delivery but there is no corresponding PickMyTrade record, gather the exact firing time and webhook status for support. If an order exists at the broker, check its order type and status before diagnosing the difference as a delivery delay. See PickMyTrade’s monitoring guide.

What should you send to support?

For a missing or delayed event, collect the details below for the same alert and account. Include the exact error, if any. Remove tokens, webhook secrets, passwords and other credentials before sharing a message or screenshot.

• PickMyTrade account email and the affected broker account identifier, shared through an appropriate support channel.
• TradingView alert name, symbol, action, quantity, timeframe, condition and firing date and time with time zone.
• TradingView webhook status and any visible PickMyTrade Alert Log message or error.
• Broker order ID, status, filled and remaining quantity, and order or fill timestamps, if available.
• A redacted alert message and screenshots that show the relevant event without exposing credentials.

Use PickMyTrade’s alert error reference and order troubleshooting guide to trace the event through each system. If the event does not appear in the Alert Log, ask support whether receiver-side records are available.

Should you resend a late alert?

Check the broker before sending a replacement. An uncertain response or missing log entry does not prove that an order was never created. The original instruction may already have produced a working order or position; replaying it can create additional exposure.

If an unwanted order is still working, use the broker’s supported cancellation control and confirm the final status. A cancel request may race with a fill, and canceling an unfilled remainder does not close any quantity already filled. Check protective orders before making changes.

If the outcome remains uncertain, pause new automated activity as appropriate and contact support with redacted records. Pausing future alerts does not itself confirm that existing broker orders were canceled.

Can a custom integration reject stale webhooks?

A custom receiver can be designed to compare an event timestamp with its own receipt time and reject messages outside a defined policy before placing an order. This is an integration design option, not a claim about a standard PickMyTrade webhook feature.

Define timestamp format, time zone, clock synchronization, maximum age, allowed clock skew, and handling of missing, malformed or future times. Test events just inside and outside the boundary, delayed deliveries, and clock disagreement. Check behavior in a demo environment.

Freshness checks and duplicate prevention solve different problems. A fresh duplicate can still cause a second order, and an old unique event can still be stale. Use stable event identifiers and an idempotency policy in any custom integration, and reconcile uncertain submissions against broker records before retrying.

Consider entries and exits separately. A rule that rejects every old message could also reject a delayed protective exit. Define and test how reductions and emergency exits should be handled; no time rule guarantees execution.

Frequently asked questions

Keep alert age and order lifetime separate

A timestamp helps reconstruct an event. A freshness rule decides whether an incoming signal is still eligible for action. GTD or another time-in-force rule governs a working order after submission. Each needs its own verification.

Start with the PickMyTrade JSON reference and test the TradingView-to-broker route in demo. If your strategy requires stale-entry rejection, ask support for the current connector-specific rule and confirm its behavior before using it live.

Disclaimer:
This content is for informational purposes only and does not constitute financial, investment, or trading advice. Trading and investing in financial markets involve risk, and it is possible to lose some or all of your capital. Always perform your own research and consult with a licensed financial advisor before making any trading decisions. The mention of any proprietary trading firms, brokers, does not constitute an endorsement or partnership. Ensure you understand all terms, conditions, and compliance requirements of the firms and platforms you use.

Also Checkout: TradingView Webhook Not Working? Step-by-Step Fixes