Simulating a broker outage in your EA testing

[Fairman]

Simulating a broker outage in your EA testing

Strategy testers assume a perfect world. Every tick arrives, every order fills, the connection never drops. Live trading isn't like that. Brokers have outages, platforms disconnect, and VPS machines restart.

You can't test outages in the regular tester, but you can test how your EA handles them on a demo account. A few things I'd try.

Disconnect the internet on the machine while the EA has an open position, wait a few minutes, then reconnect. Does the EA pick up where it left off? Does it know about the position? Does it try to open a duplicate?

Close and reopen the platform during a trade. Does the EA restore its state, like trailing stop levels or partial close status, or does it start fresh?

Simulate an order failure by placing an order with an invalid stop, or during market close. Does the EA handle the error and retry sensibly, or does it loop?

Check what happens if the EA starts when the market is closed, like on a Sunday before open.

These tests are boring, but they catch the bugs that hurt the most, because they show up in the worst moments, when you're not watching. An EA that trades well but handles disconnections badly is a risk.

[Fairman]

Keeping state outside the EA's memory helps with most of these. Global variables in MT4 and MT5 survive platform restarts. Files work too. If the EA stores things like the current trailing level, whether it already took a partial, or the last bar it processed, it can recover properly after a restart. Without that, every restart is a fresh start, which can lead to duplicate trades or lost management. It's not much code, and it makes outages much less dangerous. Test it once with a deliberate restart and you'll know whether the EA survives one.

[Fairman]

For live monitoring, the heartbeat idea helps you know an outage happened. But it's also useful for the EA itself to log when it detects a gap in ticks or a reconnection, so you can review what happened afterwards. In MT5, checking TerminalInfoInteger for the connection status on each timer event lets the EA notice disconnections. Logging the time it lost and regained connection, plus what positions were open, makes it much easier to work out whether anything went wrong. Reviewing those logs after a rough day often shows a short disconnection you never noticed while it was happening.

[FXS Prop Desk]

Simulating outages in a demo account is a practical approach: disconnect the internet for a few minutes while the EA has open trades, and see what happens when it reconnects. Does it recognise its open positions? Does it place duplicate orders?

The restart scenario is also worth testing. If the VPS restarts, the EA needs to load its state correctly and not treat existing positions as new. That kind of bug only shows up in live conditions.

[Fairman]

Testing what happens to open trades during a disconnection is the most important part. Disconnect the VPS from the internet for a few minutes while the EA has a position open on a demo account, then reconnect. Does the EA pick up the position correctly? Does it try to open a duplicate? Does it apply its trailing logic properly after reconnecting? These are things you only find out by trying, and finding them on a demo is much cheaper than discovering them live. Doing it a few times, at different points in a trade, covers more cases.

[Fairman]

Broker side outages are harder to simulate. When the broker's server goes down, you can't send orders or get prices, and the EA sees no ticks. Some EAs handle this poorly, for example by treating the lack of ticks as a frozen market or by sending orders as soon as the connection returns, at prices far from the last known level. Adding a check that compares the time of the last tick with the current time, and pauses trading if they differ by too much, helps the EA notice the problem and avoid acting on stale data.

[PTScalper]

Simulating a broker outage in your EA testing

Strategy testers assume a perfect world. Every tick arrives, every order fills, the connection never drops. Live trading isn't like that. Brokers have outages, platforms disconnect, and VPS machines restart.

You can't test outages in the regular tester, but you can test how your EA handles them on a demo account. A few things I'd try.

Disconnect the internet on the machine while the EA has an open position, wait a few minutes, then reconnect. Does the EA pick up where it left off? Does it know about the position? Does it try to open a duplicate?

Close and reopen the platform during a trade. Does the EA restore its state, like trailing stop levels or partial close status, or does it start fresh?

Simulate an order failure by placing an order with an invalid stop, or during market close. Does the EA handle the error and retry sensibly, or does it loop?

Check what happens if the EA starts when the market is closed, like on a Sunday before open.

These tests are boring, but they catch the bugs that hurt the most, because they show up in the worst moments, when you're not watching. An EA that trades well but handles disconnections badly is a risk.

Hi Fairman,

Good topic, you are right.

Strategy testers in platforms like MetaTrader 4 and MetaTrader 5 operate in a vacuum. They assume zero latency, infinite liquidity, permanent connectivity, and instantaneous order execution. Real-world live trading, however, is messy: internet connections drop, virtual private servers (VPS) undergo unexpected reboots, brokers experience server re-quotes, and weekend gaps disrupt initialization scripts.

Moving beyond standard backtesting requires Resilience and Chaos Testing on a demo account. Here is an expanded, systematic approach to stress-testing your Expert Advisor (EA) against real-world broker outages and execution failures.

[PTScalper]

Phase 1: Network Disconnection & Reconnection Testing

When your internet connection drops or your VPS loses its bridge to the broker's data center, your EA's internal loop stops receiving ticks (OnTick() ceases to fire). When connection is restored, how the EA reacts determines whether it manages your capital safely or derails.

How to Simulate: While your EA has an active open position with a trailing stop or partial close logic active, physically unplug your router's ethernet cable, disconnect your Wi-Fi, or pause your VPS network interface for 5 to 10 minutes. Then, restore the connection.

What to Look For:

Does the EA successfully re-establish synchronization with the broker's terminal state, or does it lose track of open tickets?

Does it attempt to open duplicate positions because it assumed the previous order was never sent during the disconnect window?

Verification: Check the journal/experts log to ensure the EA calls functions like PositionSelect() or iterates through open tickets (PositionGetTicket) upon re-initialization rather than relying solely on local memory variables.

[PTScalper]

Phase 2: Platform Crash & Restart Mid-Trade

Local memory inside an EA (such as global variables declared in the script file) is completely wiped when MetaTrader restarts. If your platform crashes during high-volatility news events, your EA must rebuild its state instantly from the broker's server data.

How to Simulate: Force-close the MetaTrader terminal via Task Manager (or restart your VPS) while an active trade is running and trailing stops are actively being modified. Relaunch the platform immediately.

What to Look For:

Does the EA restore its previous state (e.g., tracking whether a partial close has already been executed, or remembering high-water marks for trailing stops), or does it reset its internal counters and trigger duplicate actions?

Does it throw null-pointer errors or division-by-zero alerts during the first tick after reboot because critical tracking variables were not saved to disk or fetched from the broker?

Verification: Ensure your EA queries the broker server on OnInit() using native broker functions (PositionGetDouble, OrderGetInteger) to rebuild its state dynamically rather than depending on volatile run-time variables.

[PTScalper]

Phase 3: Order Execution & Error Handling Failures

Brokers frequently return error codes due to invalid parameters, requotes, off-quotes, or trade context being busy. An EA with poor error handling will either freeze entirely or—worse—get stuck in an infinite loop spamming the trade server.

How to Simulate: Force execution errors by hardcoding or triggering scenarios such as placing an order with an invalid stop loss (too close to current market price), trading during restricted hours, or attempting to trade when margin levels are insufficient.

What to Look For:

Does the EA capture the error code using GetLastError()?

Does it implement a sensible retry cooldown, or does it flood the broker log with hundreds of failed requests per second?

Verification: Confirm that your error-handling function categorizes errors correctly (e.g., distinguishing between fatal errors like ERR_INVALID_STOPS that require user intervention vs. temporary errors like ERR_TRADE_CONTEXT_BUSY that require a brief pause and retry).