During a Non-Farm Payrolls release, EUR/USD can move 30 to 50 pips in under 60 seconds. Tick rates spike from 1 to 5 per second to 25 to 50 per second. Spreads widen from 0.2 pips to 20 pips or more. MetaTrader CPU usage on a VPS jumps from 20% to 60%. Every component in the execution chain operates under fundamentally different conditions simultaneously.
For traders running Expert Advisors on a VPS, this is not a trading strategy problem. It is an infrastructure survival problem. MetaTrader’s tick queue silently drops price updates during these spikes. Broker bridges that deliver 30ms execution during calm markets can degrade to seconds. Liquidity providers who normally compete to fill your order actively withdraw their quotes. Shared VPS instances that perform identically to dedicated servers 99% of the time fail during the 1% that determines outcomes.
This article maps exactly how and where the execution path degrades during high-impact scheduled news releases. It is not about how to trade NFP or interpret economic data. It is about what happens to your MetaTrader terminal, your broker connection, your VPS resources, and your order execution during the most volatile seconds of the month, and what you can configure in advance to survive them.
Data is drawn from MQL5 official documentation (tick queue behavior, trade context architecture), broker execution reports (IC Markets, LMAX, Pepperstone), the LMAX Transaction Cost Analysis study of 7.1 million orders, Finance Magnates Intelligence research, VPS provider benchmarks, Bank for International Settlements reports, and documented infrastructure failures including the SNB shock of 2015, the GBP flash crash of 2016, and the CrowdStrike outage of 2024. Where a figure comes from a single source or a commercially interested party, it is flagged.
What Happens Inside MetaTrader During a News Spike
The most important infrastructure fact for EA developers is buried in MetaQuotes’ own documentation: MetaTrader does not queue ticks. It drops them.
The official MQL5 documentation states that if the event queue already contains a NewTick event or one is currently being processed, any new NewTick event is simply not added to the queue. The queue allows at most one pending NewTick at any time. If OnTick() is currently executing and one NewTick is already waiting, every subsequent tick arriving during that window is silently discarded. No error is thrown. No warning appears. The EA never knows those ticks existed.
During normal London and New York session trading, this rarely matters. EUR/USD tick rates average 50 to 300 ticks per minute depending on the broker’s tick filtering, roughly 1 to 5 ticks per second. The interval between ticks is long enough that OnTick() typically finishes processing before the next tick arrives. Tick loss under normal conditions runs below 20% on some brokers.
During NFP, FOMC, or CPI releases, tick volume spikes 5 to 10x above baseline, pushing arrival rates to 25 to 50+ ticks per second. Inter-tick intervals compress from 200ms to 20ms while EA processing time stays constant. One MQL5 forum test recorded 14 ticks arriving during a single OnTick() iteration that averaged just 21.2 microseconds to complete. The percentage of dropped ticks escalates dramatically because the arrival rate overwhelms the single-slot queue regardless of how fast the EA code runs.
This is not a bug. It is a deliberate architectural decision. MetaTrader prioritizes terminal responsiveness over complete tick delivery. But for an EA making trading decisions during a news release, it means the price data driving those decisions has gaps in it. The EA sees a series of price snapshots with missing frames between them.
Trade context contention compounds the problem
Both MT4 and MT5 process all MQL programs single-threaded internally. Every OnTick(), OnTimer(), and OnChartEvent() executes sequentially within a single EA. When an EA calls OrderSend() during broker overload, the synchronous call blocks the entire EA thread waiting for a server response. Forum reports describe OrderSend() hanging for several seconds or timing out entirely during NFP. If the call blocks for 2 to 5 seconds while ticks arrive every 20 to 40ms, the EA misses 50 to 250 ticks during a single order attempt.
MT4’s trade context architecture makes this worse. MT4 originally had only one trade context, meaning a single EA executing OrderSend() locked out every other EA on the terminal, producing waves of Error 146 (Trade Context Busy). Later MT4 builds upgraded to 8 concurrent trade contexts. MT5 shipped with 8 natively. But a terminal running 10+ EAs during NFP will still see contention even with 8 contexts, because every EA attempts to trade during the same seconds.
The error codes that appear during news events tell their own story. Error 136 (ERR_OFF_QUOTES) means the broker server cannot provide a valid price at all, common when liquidity providers have pulled their quotes. Error 138 (ERR_REQUOTE) fires when price moved between request and execution. Error 141 (ERR_TOO_MANY_REQUESTS) signals the server is overwhelmed. These are not edge cases during NFP. They are the expected operating environment.
MT5’s CopyTicks() is the only workaround
MT5 offers a critical capability that MT4 cannot match. The CopyTicks() function retrieves all ticks that actually arrived at the terminal, including those that OnTick() missed. The terminal maintains a fast-access cache of the last 4,096 ticks per symbol (65,536 for symbols with Market Depth enabled).
The recommended pattern is to call CopyTicks() at the start of each OnTick() invocation, iterating from the last-processed timestamp forward. This does not prevent tick loss in OnTick() itself, but it ensures the EA’s logic operates on complete price data rather than the gapped snapshots that OnTick() alone provides. For any EA that trades during scheduled news events, this is not optional. It is the only mechanism that provides a complete tick record during floods, and it has no MT4 equivalent.
MT5’s OrderSendAsync() provides the complementary solution for order execution. It dispatches the trade request and returns immediately, freeing the EA to continue processing ticks while the broker handles the order. In documented benchmarks, OrderSendAsync() returned in 78 to 125ms for 10 simultaneous orders versus 1,000 to 9,000ms for synchronous OrderSend() blocking on the same batch. The tradeoff is architectural complexity: results must be tracked through OnTradeTransaction() rather than checked inline, which demands fundamentally different order management code.
The Broker Execution Chain Under Stress
Between your EA’s OrderSend() call and an actual fill sits a chain of infrastructure that operates invisibly during calm markets but becomes the dominant source of execution degradation during news events.
The liquidity bridge is the first bottleneck. Software platforms like OneZero Hub, PrimeXM XCore, and Centroid connect the MT4/MT5 trade server to external liquidity providers, aggregating streaming quotes from multiple LPs into a best-bid/best-offer feed and routing orders via smart order routing. During normal conditions, well-configured A-book brokers achieve execution latency under 30ms average. IC Markets reports sub-20ms for market orders. LMAX Exchange’s internal matching engine operates at under 50 microseconds.
During high-impact releases, the bridge becomes the chokepoint. One documented case describes a bridge delay of 1.4 seconds during a gold spike, during which the liquidity provider refused most hedging trades, costing the broker $280,000 on a single client’s 12-second round trip. MT4’s trade server architecture introduces an additional floor of approximately 300 to 400ms regardless of bridge speed, a platform-level constraint that no amount of broker optimization can remove.
Liquidity providers pull their quotes before the number drops
Liquidity providers are not passive infrastructure. They are risk-managing counterparties. In the seconds before and minutes after a scheduled release, LPs withdraw their quotes to manage their own exposure. As one broker’s Head of Dealing explained publicly: the order book becomes “incredibly thin” during this window. The liquidity vacuum typically begins 2 to 5 minutes before a scheduled release and persists for 2 to 5 minutes afterward.
Spread behavior during these windows is dramatic. EUR/USD on ECN raw-spread accounts normally sits at 0.1 to 0.3 pips. During NFP, documented spreads widen to 5 to 10 pips on well-capitalized brokers, and up to 20 to 50 pips during extreme reactions. IC Markets’ worst documented spread reached 168 points against an average of 0.5, a 336x expansion. This is not a broker failure. It is the mathematical consequence of liquidity withdrawal: when the order book thins to a fraction of its normal depth, the distance between best bid and best offer expands mechanically.
For EAs, spread widening is both a cost and a signal. A spread filter that checks the current spread against a maximum threshold before every order attempt is the most basic programmatic defense. Checking SymbolInfoInteger() for SYMBOL_SPREAD in MQL5 against a threshold of 30 points (or whatever is appropriate for the pair and account type) prevents the EA from entering trades at spreads that destroy the profit expectation. But it also means the EA may not trade at all during the exact moments it was designed to capture.
Last Look amplifies the asymmetry against traders
The Last Look mechanism allows liquidity providers to hold trade requests for a window, typically 50 to 500ms, then decide whether to accept or reject after seeing whether the market has moved. During calm markets, this introduces modest friction. During news events, when prices move rapidly and directionally, it becomes a systematic disadvantage.
The LMAX Transaction Cost Analysis study, one of the most rigorous publicly available datasets in retail FX, analyzed 7.1 million orders and found that last-look liquidity costs $2.25 to $48.86 more per million traded than firm liquidity. Hold time costs reached $25 per million at 100ms, with 60% of that cost accruing in the first 10ms. Most critically, the study documented zero price improvement on last-look feeds. The slippage-to-improvement ratio was skewed as much as 9:1 against traders. During news events, when prices move rapidly in one direction, last-look rejection rates increase substantially because the LP sees that price has moved favorably for the trader and rejects the fill.
Current average hold times on major FX platforms run approximately 10 to 12ms, with thresholds recently reduced to 10 to 30ms on platforms like EBS and Cboe FX. But analysis across 25 liquidity providers found response times ranging from zero to nearly 2.4 seconds, with one LP taking 110 times longer to reject orders than to accept them.
The practical implication for VPS infrastructure planning: a trader who upgrades from a 50ms VPS to a 5ms VPS saves nothing if their LP adds a 100ms Last Look hold. The broker-side execution chain introduces latency that no VPS optimization can reduce. Understanding where your specific broker falls on the Last Look spectrum (firm liquidity, disclosed hold times, or opaque rejection rates) matters more for news-event execution than the difference between a 2ms and a 10ms VPS.
Execution model may change without notice during news
Some brokers automatically switch to B-book execution during defined high-volatility windows, then revert to normal A-book routing afterward. This means orders that would normally route to external liquidity may be internalized during exactly the moments when execution quality matters most. The switch happens server-side with no notification to the trader’s terminal.
Slippage data from brokers provides context but must be read carefully. FXCM reports 30.83% of orders receiving positive slippage versus 14.64% negative, but this covers all market conditions, not news events specifically. An independent IC Markets test of approximately 9,700 trades found 73.87% executed without slippage, with negative and positive slippage nearly symmetric at 13.28% versus 12.85%. During news specifically, these distributions shift substantially toward negative slippage on market and stop orders. FXCM’s own documentation notes that using limit entry orders to open trades around news events “may be a better option than using a stop entry order because negative slippage can be avoided,” though at the cost of potential non-execution when prices gap through the limit level.
VPS Performance Under Simultaneous Load
A VPS running 1 to 3 MetaTrader terminals during normal trading hours typically consumes 10 to 30% CPU. Each MT4 instance draws approximately 200 to 300 MB of RAM and up to 15% of a CPU core. During news events, CPU spikes to 50 to 60% are normal and transient. The danger threshold is 80% sustained, above which tick-processing lag begins and order queue latency rises. At 100%, orders queue instead of executing.
The resource numbers during news events are unforgiving. MT5 instances consume 768 MB to 1.5 GB of RAM depending on EA complexity, plus 800 MB to 1.2 GB for Windows overhead. The recommendation to maintain 25% RAM headroom means a 4 GB VPS must stay below 3 GB in use during normal operations. When available RAM drops below 15% of total capacity, MT5’s garbage collection becomes aggressive enough to disrupt tick processing. And RAM usage during tick floods increases as MetaTrader allocates additional buffers for the incoming data surge, meaning the moment you need the most headroom is the moment demand for it spikes.
The noisy neighbor problem is unique to forex
Shared VPS infrastructure introduces a failure mode that is specific to financial markets: every trader on the physical host activates simultaneously during the same news release. During normal hours, CPU oversubscription works because most EAs are idle between ticks. The provider sells more virtual CPU than physically exists, and it works because not everyone demands resources at the same time.
During NFP, this assumption breaks. Every EA on the physical server fires simultaneously. CPU steal time, the percentage of CPU cycles that the hypervisor takes from your virtual machine to service other tenants, can spike from under 1% to 5 to 15% during major market events. One benchmark found that an OpenVZ container experiencing CPU throttling during London open showed order execution drift of up to 10ms slower than a KVM-isolated instance, translating to 0.2 pips of additional slippage over a week.
AWS-style burstable instances (t2/t3 families) compound this problem through a different mechanism. These instances accumulate CPU credits during idle periods and spend them during bursts. News event processing depletes credits rapidly, and once credits are exhausted, the instance throttles to baseline performance, which can be as low as 20% of full capacity. The throttling happens precisely during the sustained processing load of a news event, not during the brief idle periods before and after.
KVM virtualization provides hardware-level isolation that container-based platforms like OpenVZ cannot guarantee. On KVM, the CPU cores allocated to your VM are dedicated at the hypervisor level. On OpenVZ, CPU is shared at the OS level with weaker isolation boundaries. For traders whose strategies depend on execution during scheduled news events, confirming the virtualization technology matters as much as the advertised CPU count.
Network degradation hits home connections hardest
Network behavior diverges dramatically between home connections and colocated VPS during news events. A Finance Magnates Intelligence study found that traders experiencing just 3% packet loss during news events had a 24% higher chance of slippage compared to traders on stable VPS connections. Three percent packet loss sounds negligible until you consider that during a 60-second NFP window with 50 ticks per second, 3% loss means 90 missed price updates.
One comparison measured home PC latency jumping to 150ms during NFP from a typical baseline, while a colocated VPS held at 0.8ms through the same event. The cause is not the home internet connection itself but the shared infrastructure it traverses: ISP backbone routers, peering exchanges, and last-mile equipment all experience congestion when financial data traffic surges globally during coordinated events.
Cross-connects within Equinix facilities bypass public internet entirely via dedicated fiber. A cross-connect between a VPS rack and a broker’s matching engine in the same facility delivers approximately 0.3 to 0.5ms round-trip time regardless of what is happening on the public internet. This immunity to external network congestion is the fundamental infrastructure advantage of colocation during news events, distinct from the raw speed advantage that applies at all times.
Why the latency advantage amplifies during news
The relationship between latency and slippage is roughly linear during calm markets but effectively multiplicative during news events, for two reinforcing reasons.
First, price velocity. During normal conditions, EUR/USD moves 1 to 2 pips per second. At 100ms latency, price moves approximately 0.1 pip during transit, barely noticeable. During NFP, price can move 20 to 50 pips per second, with documented peak rates approaching 100 pips per second in the initial algorithmic reaction. At this velocity, every millisecond of delay represents approximately 0.1 pip of adverse price movement. The same 100ms of latency that costs 0.1 pip normally costs 2 to 5 pips during a news spike.
Second, FIFO queue positioning. Brokers process orders first-in-first-out. During news events, thousands of orders flood the queue simultaneously. A sub-millisecond VPS gets orders into the queue before the wave of home-based orders arriving 80 to 200ms later. By the time those home-based orders reach the front of the queue, price has already moved substantially. The VPS advantage is not just the 80ms saved in transit. It is the price improvement from being ahead of the queue at the moment every other trader’s order arrives.
The TradingFXVPS experiment quantified this: a London VPS at 1ms latency accumulated +0.20 pips cumulative slippage over 120 trades, while a NYC VPS at 75ms accumulated -1.50 pips, a 1.70-pip difference directly attributable to latency. During NFP specifically, documented data indicates home PC traders average 2 to 5 pips slippage per market order versus 0.1 to 0.5 pips for colocated VPS. Over 12 NFP events per year on a single pair, the slippage differential costs a home-based trader an extra $228 to $540 annually on 1 standard lot, excluding all other high-impact events. Both figures come from VPS providers with commercial interest and should be treated as directional rather than definitive, but the underlying mechanism (faster queue entry during simultaneous order floods) is well-established in market microstructure research.
Each News Event Stresses Infrastructure Differently
Not all high-impact releases are equivalent from an infrastructure perspective. Each event type has a distinct volatility profile, duration of elevated stress, and recovery pattern. An EA and VPS configuration that handles NFP comfortably may fail during FOMC because the sustained load lasts four times longer.
NFP: concentrated spike, fast recovery
Non-Farm Payrolls produces the most concentrated infrastructure stress of any scheduled release. The typical EUR/USD reaction spans 30 to 50 pips in the first 60 seconds, expanding to 50 to 150 pips within five minutes on significant surprises. The April 2023 release (+303K versus +180K expected) drove EUR/USD down over 150 pips in the first five minutes.
The infrastructure timeline follows a predictable pattern. The pre-event vacuum begins 2 to 5 minutes before release as market makers withdraw quotes and spreads begin widening from roughly 1 pip to 15 to 20 pips. At the moment of release, tick rates spike 5 to 10x and the initial algorithmic reaction drives the largest price movement. Peak infrastructure stress lasts 15 to 30 minutes, with a tradeable structure typically emerging after the “15-Minute Rule” window. A sustained drift trend develops 2 to 3 hours post-release, and market conditions normalize within 1 to 3 hours.
An important calibration from TIOmarkets’ analysis of 2021 data: the maximum EUR/USD move over 5 hours was under 60 pips in 9 of 12 months. Extreme multi-hundred-pip NFP moves are the exception, not the rule. Infrastructure should be sized for the typical 30 to 50 pip reaction with headroom for the occasional outsized print, not for a worst case on every release.
FOMC: two-phase stress over a longer window
FOMC rate decisions present a unique infrastructure challenge because the stress comes in two waves separated by 30 minutes, and the total duration of elevated volatility far exceeds NFP.
Phase 1 at 2:00 PM EST is the statement release. Algorithmic systems parse the rate decision, statement text, and dot plot projections within milliseconds, potentially moving EUR/USD 50 to 100+ pips in the initial reaction. This phase produces infrastructure stress comparable to NFP.
Phase 2 at 2:30 PM EST is the press conference. The Fed Chair’s responses to questions often trigger a second wave of volatility that can equal or exceed the statement reaction. The December 2023 “dovish pivot” saw GBP/USD spike 250+ pips in the hours following Powell’s commentary.
The infrastructure implication is duration. NFP stress lasts 15 to 30 minutes. FOMC stress spans 30 to 60 minutes for the statement phase alone, with full recovery potentially taking 2 to 4 hours including press conference effects. A VPS that handles a 15-minute CPU spike comfortably may encounter memory pressure or swap behavior during a 2-hour sustained elevated load. MetaTrader’s documented memory growth during continuous high-tick-volume operation means the terminal accumulates more bloat during FOMC than during NFP, increasing the risk of degradation during the second phase precisely when the press conference may produce the larger move.
CPI, ECB, BOE, and BOJ: varying profiles
CPI releases produce a profile similar to NFP but typically shorter in duration: 20 to 50 pips in the first minute, peak volatility of 10 to 20 minutes, and recovery within 1 to 2 hours. The January 2023 CPI (6.4% versus 6.2% expected) moved EUR/USD 80 pips in five minutes.
ECB decisions feature a two-phase structure similar to FOMC, with the rate announcement followed by a press conference 30 minutes later. BOE decisions can produce 100+ pip GBP moves when vote distributions surprise. BOJ decisions present an unusual infrastructure risk: they occur during Asian session hours when GBP and EUR liquidity is extremely thin. Spreads widen more dramatically and gap risk is elevated. These are the same thin-liquidity conditions that amplified both the 2016 GBP flash crash and the 2019 JPY flash crash.
When infrastructure fails completely: three events every EA developer should study
Scheduled news events stress infrastructure that remains functional. The following events broke it entirely. They represent a different category of risk that no VPS configuration can mitigate, and understanding the distinction is essential for honest infrastructure planning.
The SNB shock of January 15, 2015 remains the most extreme infrastructure failure in modern FX. When the Swiss National Bank abandoned its EUR/CHF 1.20 floor, three days after publicly reaffirming it, EUR/CHF plunged from 1.2000 to as low as 0.8500 on some platforms. FXCM’s CEO reported bids as low as 0.20 with spreads 3,000 pips wide. Virtually all liquidity was withdrawn within one minute. The interbank market remained illiquid for approximately 45 minutes. FXCM required a $300 million emergency bailout after $225 million in client losses. Alpari UK declared insolvency the same day. Citibank lost $150 million, IG Group lost 30 million pounds, Interactive Brokers lost approximately $120 million. Stop losses were completely meaningless because there was simply nobody on the other side of the trade. This event exceeded 40 standard deviations.
The GBP flash crash of October 7, 2016 demonstrated thin-liquidity infrastructure failure. Shortly after midnight BST, GBP/USD fell from 1.2600 to as low as 1.1378 in approximately 2 minutes. A Bank for International Settlements report documented the speed precisely: in just 8 seconds, GBP/USD fell 106 pips with 252 million pounds traded on Reuters, the vast majority aggressive sells. The CME triggered its velocity logic mechanism, a 10-second trading pause, at 00:07:15. Broader market functioning took approximately 20 minutes to stabilize.
The JPY flash crash of January 3, 2019 illustrates holiday-liquidity risk. During the gap between US close and Asian open, with Tokyo markets closed for a holiday, USD/JPY dropped from approximately 109 to 104.45, over 400 pips in roughly 6 minutes. One ForexFactory user reported losing $14 million, retaining only 3.8% of a $13.5 million account. Bank of Japan research found the risk of forced liquidations was highest during early mornings on Mondays and Japanese holidays.
A July 2024 event demonstrated an entirely different failure mode. A faulty CrowdStrike software update caused global Windows crashes, taking down IC Markets entirely and affecting LMAX Global’s MetaTrader 4 retail servers. No market event occurred. A third-party software dependency disabled trading infrastructure on its own.
The distinction matters for infrastructure planning. Scheduled events (NFP, FOMC, CPI) stress your execution chain but leave it functional. You can prepare with spread filters, reduced Market Watch symbols, RAM headroom, and server-side stop losses. Tail-risk events (SNB, flash crashes) can render every protective mechanism simultaneously inoperative: stops gap through, brokers become insolvent, and liquidity vanishes entirely. The infrastructure hardening described in this article protects against the first category. Only position sizing and negative-balance protection address the second.
What Your VPS Configuration Should Handle
The preceding sections established that news-event degradation occurs at three layers: the MetaTrader terminal (tick dropping, trade context contention), the broker (bridge latency, LP withdrawal, Last Look), and the VPS (CPU steal, RAM pressure, network congestion). You cannot control the broker layer. You can control the terminal and VPS layers. The preparation below addresses both.
Before the release: reduce your resource footprint
Thirty minutes before a major scheduled release, reduce Market Watch to only the symbols your EAs actually trade. Cutting from a typical 50 to 200 symbols down to 5 to 10 eliminates thousands of unnecessary ticks per second and can lower CPU usage by 20 to 40%. This is the single largest resource reclamation available on short notice. Close any MetaTrader instances that are not running active news-event EAs. Close charts without attached EAs. Every idle chart still processes incoming tick data and consumes RAM for its price history buffers.
If MetaTrader has been running continuously for several days, restart it before the event. MetaTrader’s documented memory growth during extended operation means a terminal that has been running since Monday carries accumulated bloat by Friday’s NFP. A fresh restart clears tick history buffers, cached timeseries, and log buffer allocations, providing maximum RAM headroom for the incoming data surge.
Confirm the Windows power plan is set to High Performance. The default Balanced plan throttles CPU frequency during perceived idle periods. Between ticks, your EA is idle. Balanced mode reduces clock speed. When the tick flood arrives, the CPU must ramp back up before processing. During a news spike where every millisecond matters, this ramping delay is avoidable waste.
If your regular CPU usage exceeds 70% during normal market hours, the VPS is undersized for news-event trading. The spike from 70% to 100% during NFP will push the terminal into tick-processing lag. Upgrade before the next major release rather than discovering the limitation during it.
Server-side stop losses are non-negotiable
Every open position must have a hard server-side stop loss registered on the broker’s server before a scheduled news release. This is the single most important protective measure because it is the only one that functions independently of your terminal, your VPS, your internet connection, and your EA’s execution state.
Trailing stops freeze when MetaTrader disconnects. EA-managed dynamic stops cease adjusting when OnTick() stops firing. Grid level management halts when the EA thread hangs on a blocking OrderSend() call. All of these client-side mechanisms fail during exactly the conditions a news release creates. The server-side stop loss is the backstop that catches the worst case regardless of what happens to every other component in the chain.
For EAs that normally manage stops dynamically, the server-side stop loss should sit at the maximum acceptable loss level, the point beyond which the trade should be closed regardless of whether the EA is functioning. If the EA normally tightens stops as profit increases, the server-side stop provides the fallback. If the connection drops and the EA cannot tighten further, the worst outcome is a larger-than-normal loss rather than an unmanaged position during a 50-pip spike.
Standard stop losses execute at the next available price after being triggered, which means during a gap, a stop at 1.0900 may fill at 1.0850 or worse. Guaranteed Stop Loss Orders (GSLOs) ensure execution at the specified price regardless of gaps but are available only from select brokers (IG, OANDA, City Index), only on proprietary platforms rather than standard MT4/MT5, and carry a premium fee. This creates a tension between execution model preference and downside protection that each trader must resolve based on their strategy and broker.
Programmatic defenses inside the EA
A spread filter is the most basic and most effective programmatic defense. Checking the current spread against a maximum threshold before every order attempt prevents the EA from entering trades at spreads that destroy the profit expectation. A threshold of 30 points is common for EUR/USD, though the appropriate value depends on the pair, account type, and strategy. The tradeoff is explicit: the filter may prevent the EA from trading during the exact seconds it was designed to capture. That is acceptable. Trading at a 20-pip spread when the strategy targets 15 pips is not.
Time-based lockout windows provide a second layer. MT5’s native Economic Calendar API provides server-synchronized event data suitable for creating automated lockout periods around scheduled releases. MT4 lacks this API and requires external data from ForexFactory or Investing.com, typically communicated between EAs via GlobalVariables. The pattern GlobalVariableSet(“NewsLockout”, 1.0) checked by all trading EAs before entry is simple but effective coordination.
For tick-time monitoring during news, OnTimer() is preferred over OnTick() because timer events execute at fixed intervals regardless of tick flood conditions. OnTick() is flooded during news and may miss signals, while a 1-second timer provides reliable periodic execution for monitoring functions. For EAs that must process every tick during news, the MT5 CopyTicks() approach described in the MetaTrader section is the only reliable method.
The minimum VPS specification for news-event trading
The minimum specification for an EA that actively trades during scheduled high-impact releases is 2 dedicated (not shared) vCPUs at 3.5+ GHz, 4 GB RAM, NVMe SSD storage, and a network connection colocated in the same Equinix facility as the broker. KVM virtualization provides hardware-level isolation that container-based OpenVZ cannot guarantee during simultaneous load from neighboring tenants.
This specification exceeds what most EAs need during normal trading. A swing EA that avoids news events entirely runs comfortably on a shared 2 GB VPS. The premium for dedicated cores and colocation is justified only for strategies that actively trade during the volatile seconds surrounding scheduled releases. For strategies that lock out during news and resume afterward, the standard VPS guidance from our EA infrastructure guide applies.
FAQ
Should I stop my EA from trading during news events entirely?
It depends on the strategy. An EA targeting 50+ pip swing trades on H4 gains nothing from trading during the 60-second NFP spike and risks adverse fills at widened spreads. Locking out for 15 to 30 minutes around scheduled releases costs nothing and eliminates the infrastructure risk entirely. An EA specifically designed for news reaction trading needs to trade during those seconds by definition, but it also needs the infrastructure to support it: dedicated CPU cores, colocation near the broker, CopyTicks() for complete tick data, OrderSendAsync() for non-blocking execution, and spread filters to avoid entries at 20-pip spreads. Most retail EAs fall into the first category. The honest assessment is that unless your EA was specifically architected for news-event execution on MT5 with async order handling and tick recovery, locking out is the higher-expectancy choice.
Does my VPS provider matter more during news than during normal trading?
Yes, substantially. During normal trading, shared and dedicated VPS plans perform nearly identically because resource contention is low. During news events, shared plans experience CPU steal from neighboring tenants, burstable instances exhaust CPU credits, and container-based virtualization provides weaker isolation than KVM. If your strategy actively trades during scheduled releases, confirm three things with your provider: the virtualization technology (KVM preferred), whether CPU cores are dedicated or oversubscribed, and whether the VPS is colocated in the same Equinix facility as your broker. During normal trading hours, these distinctions are academic. During NFP, they determine whether your order enters the queue ahead of or behind thousands of other orders.
Can I protect against flash crashes like the SNB event with better infrastructure?
No. The SNB shock, the GBP flash crash, and the JPY flash crash all involved the simultaneous failure of liquidity, execution infrastructure, and in some cases broker solvency. Stop losses gapped through by hundreds or thousands of pips. Liquidity providers withdrew entirely. Interbank markets went dark for 45 minutes. No VPS configuration, no colocation, no spread filter would have prevented losses during these events. The only protections that function during tail-risk events are position sizing (never risking more than you can afford to lose on any single position), negative-balance protection (offered by brokers regulated under ESMA rules, which prevents account equity from going below zero), and avoiding concentrated exposure in thin-liquidity sessions (Asian hours for GBP and EUR, holidays for JPY). Infrastructure protects against scheduled event stress. Risk management protects against tail events.
How do I know if my broker uses Last Look?
Most retail brokers do not disclose Last Look practices transparently. LMAX Exchange is the most prominent venue that explicitly operates without Last Look, using firm liquidity where all orders are filled at the displayed price or rejected. ECN brokers using aggregated LP feeds almost certainly route through at least some LPs that employ Last Look. The practical indicators are: consistently asymmetric slippage (more negative than positive on market orders), high rejection rates during fast-moving markets, and execution times that vary substantially between calm and volatile conditions. If your broker publishes execution quality reports (IC Markets and Pepperstone both do), compare fill rates and slippage distributions during news events versus normal conditions. A large divergence suggests Last Look or similar mechanisms activating during volatility.
What is the difference between a spread filter and a news lockout?
A spread filter is reactive: it checks the current spread before every order attempt and blocks entry when spread exceeds a threshold. It works during any market condition, not just scheduled events. A news lockout is proactive: it blocks trading during a defined time window around a scheduled release regardless of current spread. Both are useful and complementary. The spread filter catches unexpected widening outside scheduled events (flash crashes, liquidity gaps during session transitions). The news lockout prevents trading during the entire pre-event vacuum when spreads may be marginally wider but liquidity is already thinning in ways the spread number alone does not capture. Running both provides defense in depth.
Is MetaQuotes’ built-in VPS sufficient for news-event trading?
The MetaQuotes VPS achieves sub-3ms latency to 96% of broker servers and handles auto-restart natively, which are genuine advantages. However, it provides a maximum of 3 GB RAM with no ability to monitor CPU usage, no RDP access for running monitoring scripts, no way to configure Windows Defender exclusions, and no control over the virtualization environment or neighboring tenants. You cannot verify whether the instance uses dedicated or shared CPU, and you cannot restart MetaTrader independently of the VPS service. For news-event strategies where dedicated cores, RAM headroom, and monitoring are critical, a full Windows VPS with KVM isolation and confirmed Equinix colocation provides the control that the MetaQuotes VPS does not. For EAs that lock out during news and trade only during calm conditions, the MetaQuotes VPS is perfectly adequate.
References
- MQL5.com Documentation. NewTick event queue behavior: “If the queue already contains the NewTick event or this event is in the processing stage, then the new NewTick event is not added to the mql5 application queue.” CopyTicks() function and terminal tick cache (4,096 per symbol, 65,536 with Market Depth). OrderSendAsync() asynchronous execution model and OnTradeTransaction() result handling. SymbolInfoInteger() for SYMBOL_SPREAD. Economic Calendar API for server-synchronized event data. Error codes 136 (ERR_OFF_QUOTES), 138 (ERR_REQUOTE), 141 (ERR_TOO_MANY_REQUESTS).
- MQL5.com Forum. Tick arrival measurements: 14 ticks during single OnTick() at 21.2 microseconds average. OrderSend() blocking behavior during news events (“hanging for plenty of time or even timing out”). Trade context architecture: MT4 original 1 context, later builds upgraded to 8, MT5 shipped with 8 natively. OnTimer() versus OnTick() reliability during tick floods.
- LMAX Exchange. Transaction Cost Analysis study of 7.1 million orders: last-look costs $2.25 to $48.86 more per million traded, hold time costs $25/million at 100ms with 60% accruing in first 10ms, zero price improvement on last-look feeds, slippage-to-improvement ratio up to 9:1 against traders. Internal matching engine latency under 50 microseconds.
- The Full FX. Analysis of 25 liquidity providers: Last Look response times ranging from zero to 2.4 seconds, one LP taking 110x longer to reject orders than to accept them. Current average hold times of 10 to 12ms on major FX platforms.
- IC Markets. Execution quality data: sub-20ms average for market orders during normal conditions. Worst documented spread of 168 points against 0.5 average (BrokersView assessment). Independent test of approximately 9,700 trades: 73.87% no slippage, 13.28% negative, 12.85% positive. CrowdStrike outage July 2024 taking IC Markets entirely offline.
- Finance Magnates Intelligence. Packet loss impact study: 3% packet loss during news events correlating with 24% higher chance of slippage. Broker casualty reporting for SNB shock (FXCM $300M bailout, Alpari UK insolvency, Citibank $150M loss, IG Group 30M pounds, Interactive Brokers $120M).
- Bank for International Settlements. GBP flash crash October 7, 2016 report: 106 pips in 8 seconds (00:07:03 to 00:07:11 BST), 252 million pounds traded on Reuters, CME velocity logic triggered at 00:07:15. Market stabilization within approximately 20 minutes.
- ForexFactory Forum. Normal-conditions tick loss measurements. EUR/USD tick rate documentation during news versus calm conditions. User “bluepanther” JPY flash crash report: $14 million loss, 3.8% of $13.5 million account retained.
- VPS Provider Data. TradingFXVPS latency experiment: London VPS at 1ms versus NYC VPS at 75ms, 1.70-pip slippage difference over 120 trades. Home PC versus colocated VPS slippage during NFP: 2 to 5 pips versus 0.1 to 0.5 pips. FXVPS.biz: normal CPU 10 to 30%, news spikes 50 to 60%, 80% danger threshold. OpenVZ versus KVM benchmark: 10ms execution drift under throttling. Published by providers with commercial interest; directional findings consistent with market microstructure research but not independently replicated.
- Broker Bridge Documentation. OneZero Hub, PrimeXM XCore, and Centroid bridge architectures. Documented bridge delay of 1.4 seconds during gold spike costing broker $280,000. MT4 trade server latency floor of 300 to 400ms. B-book switching during high-volatility windows.
- FXCM. Execution quality data: 30.83% positive slippage versus 14.64% negative across all conditions. Recommendation for limit entry orders around news events. CEO statement during SNB shock regarding institutional FX market failure.
- TIOmarkets. 2021 NFP analysis: maximum EUR/USD 5-hour move under 60 pips in 9 of 12 months. NFP typical profile and 15-Minute Rule window documentation.
- Deutsche Bank / Bank of Japan. JPY flash crash January 3, 2019 analysis: USD/JPY drop from 109 to 104.45 in approximately 6 minutes, AUD/JPY 7% decline. BOJ research on forced liquidation risk during Monday early mornings and Japanese holidays.
- Equinix Data Centers. Colocation hubs: NY4/NY5 (Secaucus, NJ), LD4/LD5 (Slough, UK), TY3 (Tokyo), SG1 (Singapore). Cross-connect round-trip time approximately 0.3 to 0.5ms within same facility.
Editorial Note
This article examines how forex trading infrastructure degrades during high-impact scheduled news releases: MetaTrader tick processing, broker execution chains, VPS resource behavior, and the amplification of latency effects during price velocity spikes. It does not constitute financial advice, trading strategy recommendations, or endorsement of any specific broker, VPS provider, or trading approach.
The distinction between scheduled news events and tail-risk events is critical. The infrastructure preparation described in this article addresses scheduled releases (NFP, FOMC, CPI, central bank decisions) where the execution chain remains functional under stress. Tail-risk events (SNB 2015, flash crashes, third-party software failures) can simultaneously disable protective mechanisms across the entire execution chain, including stop losses, broker solvency, and liquidity itself. No VPS configuration mitigates this category of risk. Position sizing and negative-balance protection are the only defenses.
Tick-dropping behavior is documented by MetaQuotes in official MQL5 documentation and is a deliberate architectural decision, not a bug. EA developers should verify tick delivery rates on their specific broker and platform version. The CopyTicks() workaround described applies to MT5 only and has no MT4 equivalent.
Spread widening figures, slippage distributions, and execution speed data cited in this article reflect specific measurement periods and broker configurations. Actual execution quality varies by broker, account type, liquidity provider, time of day, and market conditions. The LMAX TCA study represents the most rigorous publicly available dataset on Last Look costs but reflects institutional-grade order flow; retail execution characteristics may differ.
VPS latency experiments cited from TradingFXVPS and FXVPS.biz were published by providers with commercial interest in demonstrating VPS value. The directional findings (closer VPS reduces slippage, colocation advantage amplifies during news) are consistent with market microstructure research and broker execution data, but the specific pip figures should be treated as indicative rather than guaranteed outcomes.
