TLDR: A delayed TradingView webhook may actually be a late condition, a bar-close alert, transport latency, receiver queue time, broker response time, or fill timing. Use synchronized UTC clocks and one event identifier to timestamp condition recognition, TradingView's alert log, network-edge receipt, application acceptance, queue processing, order submission, broker acknowledgement, and fill. Optimize only the stage that the evidence identifies.
Stop Executing Trades By Hand.
UMT Automator turns your TradingView or NinjaTrader strategy into automatic, hands-free execution — no code, no webhooks, no missed signals. Prefer a ready-made edge? Browse UMT's tested Strategies & Indicators built for both platforms.
Free 7-day trial on the Automator · No credit card required
“The webhook was late” often describes the final symptom rather than the cause. A webhook cannot be sent before the alert condition becomes true, and an order cannot be filled before the broker receives and accepts it. Separate those stages before changing alert frequency or server architecture.
If the webhook stack itself is creating too many moving parts, UMT Automator provides a browser-based workflow for eligible TradingView strategies without a user-configured webhook, JSON payload, broker API key, or custom middleware server.
What Does “Delayed” Mean?
Choose two timestamps before diagnosing latency. Examples include:
- Market event to alert-log entry.
- Alert-log entry to receiver arrival.
- Receiver arrival to order submission.
- Order submission to broker acknowledgement.
- Broker acknowledgement to fill.
Each interval has a different owner and remedy. Do not compare a chart's historical bar timestamp directly with a local notification time and conclude that the webhook transport caused the entire gap.
Build an Alert-to-Order Timeline
| Stage | Timestamp to capture | What a gap suggests |
|---|---|---|
| Strategy or indicator condition | Calculation or signal time | Execution model, data update, bar-close logic. |
| TradingView alert | Alerts Log trigger time | Condition or alert-frequency behavior. |
| Network edge | First byte received | Webhook transport, DNS, TLS, routing. |
| Application acceptance | Validated and durably queued | Parsing, authentication, database, or app work. |
| Worker processing | Queue start and finish | Backlog, capacity, retry, dependency delay. |
| Order submission | Request sent to broker | Middleware processing. |
| Broker response | Acknowledgement or rejection | Broker, connection, account, or venue. |
| Fill | Execution report time | Marketability, liquidity, order type, venue. |
Synchronize systems to a reliable time source and store timestamps in UTC with milliseconds where available. Add a unique correlation identifier to the message and preserve it across the receiver, queue, and broker adapter. Avoid putting credentials or sensitive account information in that identifier.
Was the Alert Waiting for the Condition or Bar Close?
TradingView alert frequency matters. “Once per bar close” intentionally waits for the bar to close. “Once per bar” and “All” behave differently, but the script's own calculation and alert logic still determine when an event can occur.
Strategies normally calculate according to TradingView's strategy execution model. Enabling intrabar calculation or changing frequency can materially alter signal behavior. Do not change it only to make a timestamp earlier. Confirm that the strategy was designed and tested for that calculation mode.
Also distinguish a condition that is true from a crossing event. A crossing alert requires the series to move from one side of the threshold to the other after the alert is active. A state that was already true may not create a new trigger.
Could a Notification Schedule Be Mistaken for Delay?
TradingView's notification schedules block outbound channels, including webhooks, outside the selected window while still logging the trigger. That behavior is suppression, not a queue that promises later delivery. If events disappear during certain hours, inspect the schedule instead of interpreting the missing interval as webhook latency.
How Long Did Webhook Transport Take?
Compare TradingView's trigger time with the earliest receiver-edge timestamp. Keep in mind that independent clock error can look like transport delay. Verify time synchronization before trusting small differences.
TradingView documents a three-second response limit. If the remote server takes longer, the request is cancelled. That is a timeout rather than ordinary successful delivery latency. TradingView does not publish a general promise that every webhook will arrive within a particular smaller interval, so avoid inventing an expected average.
Did the Receiver Create the Delay?
Measure time spent on authentication, JSON validation, database access, queue insertion, and downstream calls. A receiver should not wait for a broker round trip before answering TradingView if that risks exceeding the three-second limit.
A quick acknowledgement is safe only after the event has been validated enough and stored durably. Otherwise, an HTTP success can hide a dropped order request. Monitor queue age, worker capacity, retries, dead-letter events, and duplicate suppression.
Did a Retry Add Five Seconds?
TradingView documents resubmission when a receiver returns HTTP 500 through 599, except 504. It can resend after five seconds, up to three resends after the original request. A downstream event that appears roughly five seconds later may therefore be a retry, not a slow first delivery.
Record the HTTP status returned for every attempt and make the receiver idempotent. A recovery during the retry window should not create duplicate orders.
Was the Broker or Market the Delayed Stage?
An accepted webhook does not equal an accepted or filled order. Measure:
- Time from receiver acceptance to broker submission.
- Time from submission to broker acknowledgement or rejection.
- Time from acknowledgement to partial or complete fill.
Order type, price, liquidity, market state, account restrictions, and venue behavior can affect execution. Do not label fill time as webhook delay.
A Safe Latency Test
- Use paper trading or a non-ordering receiver.
- Synchronize every participating system clock.
- Create one unique event identifier.
- Trigger one controlled alert.
- Export timestamps from each stage.
- Calculate each interval separately.
- Repeat enough times to distinguish a pattern from one outlier.
Document median and high-end observations from your own system rather than promising a universal latency number.
How UMT Automator Simplifies the Timeline
UMT Automator connects supported TradingView strategy activity with broker-side automated trade execution through a browser-based workflow. It removes the user-operated webhook endpoint, JSON parser, hosted queue, and custom broker middleware from the setup.
It does not remove every source of latency. TradingView, the browser, device load, internet connectivity, broker processing, and market execution still matter. Keep the required browser tab open, use stable internet, and evaluate the full workflow in paper trading.
Review the UMT Automator requirements, then start the current free 7-day trial to measure the workflow with an eligible strategy.
Frequently Asked Questions
Why is my TradingView webhook delayed until bar close?
The alert may use Once per bar close, or the script may calculate and emit its signal at bar close. Confirm the alert frequency and strategy execution behavior before changing either.
Does TradingView guarantee a webhook delivery time?
TradingView documents a three-second receiver response limit, but that is not a promise of a particular end-to-end order or fill time.
Why did my webhook arrive about five seconds later?
If the first attempt received most 5xx responses, TradingView's documented resubmission process may send another attempt after five seconds. Check receiver status logs and duplicate identifiers.
Is fill delay the same as webhook delay?
No. Webhook transport, order submission, broker acknowledgement, and market fill are separate stages.
Risk disclaimer: Automated trading involves substantial risk. Test timing and order behavior in simulation or paper trading. No automation method can guarantee alert timing, connection latency, broker response, fills, synchronization, or profitability.
