You built the setup. You tested it on a quiet afternoon. Every alert fired, every trade landed, the fill matched the chart. Then the first NFP print hit and it fell apart — silence on some alerts, and a fill several ticks away from where the alert triggered on others. Same webhook, same script, opposite result.
This isn’t a bug in your setup. It’s your setup meeting conditions it never saw in testing. Here are the five reasons a TradingView webhook that passes every calm-market test breaks during a news release, and what you can actually do about each one.
TradingView documents a hard limit: if the receiving server doesn’t respond within three seconds, the request times out and is dropped. The causes it lists are an overloaded server or network issues — including DNS resolution time, which eats into the same window before your endpoint even sees the request (TradingView Support).
In calm markets your endpoint answers in milliseconds, so you never come near the ceiling. During a release, alerts fire in bursts. If you host your own webhook receiver on a small VPS, that box is now parsing payloads, calling a broker API, and handling errors in the same window. Cross three seconds and TradingView doesn’t wait — the signal is gone. That’s your “silence.”
Fix: keep the receiving endpoint’s only job fast. Accept the POST, return 200 immediately, then do the broker work asynchronously after you’ve already answered TradingView. If you’re on a shared or underpowered VPS, that’s the first thing to size up.
This one is broker-side and it hits everyone, automated or manual. In testing the spread is tight, so a market order fills close to the chart price. During NFP or CPI the spread can widen to many times its resting value for a few seconds. A market order sent into that window gets the worst available price — that’s your “bad fill,” and it has nothing to do with your webhook working correctly.
Fix: a maximum-spread check before execution. Set a spread ceiling; if the live spread is above it when the signal arrives, skip the trade instead of taking the fill. This is the single guardrail that turns a bad fill into a decision — more on it below.
Even if the webhook lands and the spread is acceptable, the broker still has to fill you. During the release, liquidity thins while order flow spikes, so your market order can be requoted or slipped. This is broker-and-liquidity behaviour; the alert layer doesn’t control it, and no copier removes it.
Fix: there’s no signal-side switch for broker slippage. Use limit-style handling where your workflow supports it, avoid firing market orders into the first seconds of a release, and size positions for the execution you’ll actually get during news — not the clean fills you got in testing.
Real-time systems — TradingView’s dispatch and most receivers, ours included — process signals as they arrive and don’t replay missed ones. If a webhook times out, or your terminal blips its connection during the release, that signal isn’t queued for later. It’s gone. During news a single missed entry — or, worse, a missed exit — is exactly when it costs the most.
Fix: you can’t recover a dropped signal after the fact, so the work is upstream. A stable connection, a Receiver running on a VPS instead of your laptop, and connection-drop alerts so you learn the link died within seconds rather than finding out from your P&L.
This is the part almost nobody frames directly. A calm-market test can’t fail the way news fails, because the failure conditions don’t exist in calm markets. The three-second window is never stressed. The spread never blows out. The book is never thin. Your test wasn’t wrong — it just never met the market state that breaks the chain.
The only honest test of a news-time setup is a news-time setup: run it live, small, through one release, and watch where it actually breaks. Everything above is a candidate; the release tells you which ones are yours.
| Failure mode | Root cause | Fixable? | Impact |
|---|---|---|---|
| Alert fires, no trade | 3-second timeout on self-hosted receiver | Yes — async endpoint, right-sized VPS | Critical |
| Bad fill, price far from alert | Spread widens on news release | Yes — Max Spread filter | Critical |
| Slippage on market order | Thin liquidity during release | Partially — limit orders, position sizing | High |
| Signal lost during terminal drop | No replay; real-time only | Partially — VPS, Telegram drop alerts | High |
| Setup “works” in testing | Calm-market test never stresses the chain | Yes — test live through one release | Moderate |
Split the causes into two piles.
The maximum-spread check is the highest-value guardrail here, because it converts a bad fill into a decision rather than an accident. The three-second timeout is the second — and it’s the one where architecture actually matters.
This matters if you automate TradingView alerts into MT4, MT5, NinjaTrader 8, or cTrader and you trade through or around news.
It doesn’t matter if you’re a swing trader holding for days — a few seconds of release spread won’t touch your entry, so close the tab, do not spend €25 with us. It won’t help if the underlying strategy loses money; a clean fill on a bad trade is still a bad trade. And if your broker sits in a different region from your execution infrastructure, some of the latency here is geography you can’t configure away.
For intraday and scalping automation that runs through news, here’s where the Nordman Connector architecture addresses Reasons 1 and 2 directly.
On the three-second timeout: because the Receiver runs execution locally and the cloud only validates and routes the webhook — our routing leg measured at ~0.1–0.15 seconds on our production infrastructure, ~0.5 seconds end to end — the receiver response is fast by design. Self-hosted scripts that do broker work synchronously are the ones that fail this window; the Receiver doesn’t. If you want the full picture of what that execution speed does and doesn’t change, we covered it separately.
On the spread: you set a Max Spread limit locally in your terminal. The Receiver checks the live spread against your ceiling before executing and skips the trade when the spread is wider than you allow. It won’t recover a missed signal — nothing does — but it stops you taking the worst fill of the day.
For a concrete MT4 setup, this is available in the TradingView to MT4 Trade Copier. The same controls cover TradingView into MT5, NinjaTrader 8, and cTrader. You can also watch the full TradingView-to-terminal path end to end.
Need something custom built? We develop automation to order → MT4 programmers for hire
Nordman Algorithms provides software infrastructure for trade automation and does not offer financial advice, trading signals, or managed trading services. This article is for informational and educational purposes only. Trading leveraged instruments such as Forex and CFDs carries a high level of risk and may not be suitable for all investors — only risk capital should be used. Full Risk Disclosure: https://www.nordman-algorithms.com/risk-disclosure/
