Execution Times and Signal Speed
Diagnosing reports of slow webhook signal execution: where the time goes, which numbers are trustworthy, which are clock-skew artifacts, and how to resolve them.
Overview#
Some users report that their TradingView signals "take several seconds" to reach MT5. In nearly every case, the server side is doing its job in sub-100 ms and the apparent slowness comes from one of three places: the trader's MT5 PC clock being out of sync, the dashboard's polling interval, or genuine but external latency in the trader's broker or internet connection.
This article explains what the platform measures, how to read it, and how to fix it.
What the platform actually measures#
A signal goes through these timestamps (all on the relay server's clock, a single source, trustworthy), plus one duration reported by the EA:
| Stage | When it happens |
|---|---|
| Webhook received | Your alert reaches PineHook, before auth, rate-limit, or parsing. The true start of delivery. |
| Validated | Just after the initial receive checks (the fallback start used for older records). |
| Queued for your EA | Your signal is placed on the delivery queue for your EA. |
| Sent to your EA | Your signal is handed to your connected EA. |
| Filled (EA acknowledged) | Your EA confirms the fill back to PineHook. |
| Broker fill time | A duration your EA measures: how long your broker took to fill the order. |
The dashboard's Signal Logs latency cell shows a headline total with a D / E / B breakdown beneath it:
- Delivery (D): PineHook's own processing, from the webhook arriving to the signal being queued for your EA. Excludes any intentional
delay=, queue, or offline-reconnect wait. Typically sub-50 ms. Blank (--) on blocked or rejected signals. - Execution (E): from PineHook handing the signal to your EA to the EA's fill confirmation, excluding the broker's fill time (that's B). Typically 70-300 ms.
- Broker Fill (B): the time your broker took to fill the order, measured inside the EA on a single monotonic clock. This is outside PineHook's control and is deliberately not added to the headline total. Only appears when your EA build reports it (newer EAs); older EAs show no B and E keeps the full round-trip.
The headline total on each row is D + E, the latency PineHook controls. Broker fill (B) is shown for transparency but never folded into the total. D and E are server-clock based; B (broker fill) is measured inside the EA on its own monotonic clock. All three are always non-negative. If they look normal but you still feel things are slow, the issue is somewhere else (see below).
Reading the D / E / B breakdown (read this first)#
Each Signal Logs row shows the headline total with the three components beneath it. Hovering any of them explains it:
- D (Delivery): how long PineHook took to hand your signal off to your EA after the webhook arrived. Our server-side work, before the EA.
- E (Execution): time from leaving our server to your EA's confirmation, excluding broker fill (shown as B). The EA + WebSocket round-trip we control.
- B (Broker Fill): your broker's fill time, outside our control. Not counted in the signal's total latency. Only present when your EA reports it.
If a signal looks slow, which component is large tells you where the time went:
| Pattern | Most likely cause |
|---|---|
| B (Broker Fill) is the big number | Your broker is slow (retail FX, requote, news spike). Outside PineHook, and already excluded from the total. |
| E is large but B is small or absent | The WebSocket round-trip to your PC is slow (your internet, or distance from the NYC3 server), or a complex multi-target signal kept the EA busy. |
| D (Delivery) is large | Rare. Usually a cold settings cache on the first signal after the EA was idle; the next signals are fast. |
| No B badge at all | Your EA build predates broker-fill reporting. Update the EA so broker time is isolated as B. |
| All three normal but signals still feel slow | You may be reading the wrong number. See "Common false alarms" below. |
Common false alarms (clock-skew, polling, and lookups)#
Clock-skew on the MT5 PC#
The EA's acknowledgement and the broker's confirmation timestamps are stamped on the trader's PC clock and the broker's server clock respectively. If your Windows clock isn't synced to UTC (common on home PCs without auto-time-sync), those timestamps can be 1-3 seconds off from the platform's server clock. Any tool, log, or third-party script that compares those timestamps against the alert time or server time will show "several seconds" of phantom slowness.
How to spot it: compare a signal's line time in the MT5 "Experts" tab against that same signal's server-clock latency in Signal Logs. If your Windows clock is drifting, the two won't line up even though the server-clock latency columns are sub-second, and that gap is the drift, not real execution slowness. If you're unsure, contact support: we can read the exact clock offset recorded for your license (a value over plus/minus 500 ms means the terminal clock isn't synced).
Resolution:
- On the Windows PC running MT5: Settings → Time & language → Date & time → "Set time automatically" ON.
- Hit "Sync now" under the same screen.
- Restart MT5 (the EA picks up the new clock on the next handshake).
- Re-test. The new EA build's timestamps are millisecond-precision, so the next clock-offset reading will be accurate within ~10 ms.
Signal Logs refresh#
The dashboard's Signal Logs page does not auto-poll. A brand-new signal won't appear until you refresh (use the Refresh button on the page). That's UI refresh latency, not execution latency. Refresh before deciding a signal is slow.
EA Support Log timestamps in MT5#
The "Experts" tab inside MT5 prints log lines using the MT5 terminal's local clock (which is the broker's server time, often in a non-UTC timezone like GMT+2/+3). Comparing those line times against UTC alert times produces multi-hour or multi-second mismatches that are pure clock differences, not latency.
Diagnosis flow#
When you suspect slow execution:
- Check whether your MT5 PC clock is synced. If the "Experts" tab line times don't line up with the server-clock times in Signal Logs, or support confirms a clock offset greater than plus/minus 500 ms, that's the cause; walk through the Windows time-sync resolution above. Stop here.
- Open Signal Logs for the relevant license, find a slow signal, and read its D / E / B breakdown.
- If B (Broker Fill) is dominant: external (your broker / news / requote). Outside PineHook, and already excluded from the total.
- If E is large with little or no B: external (your internet / distance), or a complex multi-target signal kept the EA busy.
- If D, E, and B are all normal (total less than 500 ms): you may be reading the wrong number; it's likely one of the false alarms above.
What is NOT the cause#
- The relay server. Server-side webhook processing is consistently 0-1 ms.
- The signal queue. Queue dwell is 10-80 ms typical.
- The WebSocket delivery. Hand-off from server to EA is bounded by the network RTT.
- Subscription tier / rate limits. Rate-limit hits would appear as REJECTED rows in Signal Logs with a clear reason.