Forex EA / Bot Stopped Trading: Why Your Expert Advisor Isn't Opening Trades

Start by ruling out the boring layer

Before touching strategy logic, it’s worth working through the boring, mechanical layer first, because it accounts for a large share of “my EA stopped trading” reports and it’s the fastest thing to check. AutoTrading has to be enabled both in the terminal’s toolbar and in the EA’s own properties — it’s easy for one to get toggled off during a restart or update without the other. The terminal needs an active connection to the broker’s server, visible in the bottom-right connection indicator, and a dropped connection during a VPS reboot or a local network blip will silently halt execution without necessarily throwing an obvious error. The account needs sufficient free margin to open the position size your lot_size field specifies; if a previous trade’s floating loss has eaten into margin, the platform will reject new orders without necessarily notifying you outside the Experts log. None of this is interesting, but it’s disqualifying, and it takes two minutes to check before assuming the problem is deeper.

The Experts and Journal logs are the actual diagnostic tool

MT5 keeps two separate logs that matter here, and people often check only one. The Journal tab logs terminal-level and connection-level events — disconnections, login failures, trade server rejections. The Experts tab logs what your EA itself is printing and any runtime errors it’s throwing, including things like array out-of-range errors or failed indicator handle initialization that would silently prevent your trade logic from ever reaching the order-send call. If your EA isn’t opening trades and you haven’t looked at both logs, you’re diagnosing blind. A Print() statement placed right before your order-send call, logging the values of every entry condition your logic checks, turns “it’s not trading” into “here’s the exact condition that’s false and why,” which is a different order of problem entirely.

Time zones are a quieter failure mode than they should be

If your JSON config restricts trading to specific hours — start_hour and end_hour fields defined against UTC because that’s how session boundaries are documented — but your EA is reading TimeCurrent() or a similar function that returns the broker’s server time rather than UTC, you have a silent mismatch that will make the EA look broken during exactly the hours you expect it to be trading. Broker server time is frequently offset from UTC by two or three hours, and that offset itself changes with daylight saving transitions in ways that don’t always track any particular real-world time zone consistently. An EA that appears to skip its entire intended trading window, or that trades a few hours later than expected, is very often not a logic bug at all — it’s a broker-time versus UTC mismatch that needs an explicit offset correction rather than an assumption that TimeCurrent() already returns UTC.

Session and volatility filters can silently veto every setup

A lot of pattern-based strategies include a filter that requires a minimum recent range, a minimum spread ceiling, or a specific volatility condition before allowing entry, and these filters are usually the right design choice — they’re what keeps a strategy from trading garbage setups during dead, illiquid stretches. But they’re also a common cause of an EA that appears to have simply stopped working, because the filter is doing exactly what it was built to do in market conditions that have shifted. A widened average spread during a low-liquidity holiday period, or a compressed range during an unusually quiet stretch of the Asian session, can push every incoming setup below your filter’s threshold for days at a time. This isn’t a bug — it’s the filter functioning correctly against a market that’s temporarily behaving differently than it was when you tuned the threshold. The fix isn’t to lower the filter reflexively the first time this happens; it’s to check whether the filter is actually firing (visible in your Experts log print statements) and whether the underlying market condition that triggered it looks like ordinary variance or an actual regime shift worth investigating separately.

Symbol-specific changes on the broker side

Brokers occasionally change contract specifications, trading session hours, or suspend trading entirely on specific symbols, sometimes without much notice — around rollovers, low-liquidity holiday periods, or after regulatory changes. If your EA references a symbol string directly and the broker has appended or changed a suffix on it (a common one being something like a “.raw” or “.pro” suffix change on an account type switch), OrderSend calls will fail silently against a symbol that technically no longer matches what your code is requesting, or that the broker’s server no longer accepts the trade parameters for. Checking the symbol’s current trading session and contract specification directly in the terminal’s Market Watch properties, and comparing it against what your EA is hard-coding, catches this category of failure quickly, and it’s worth doing whenever an EA that was working reliably suddenly stops without any code change on your end.

Filling mode and order rejection

A less obvious plumbing issue is filling mode mismatch. MT5 supports different order filling policies (Fill or Kill, Immediate or Cancel, Return), and not every broker or symbol supports every mode. An EA hard-coded to request a filling mode the broker’s current setup doesn’t support will have its orders rejected at the server level, which shows up in the Journal as a trade request error rather than as any indication your entry logic is at fault. Checking the symbol’s supported filling modes and matching your order-send request to one of them resolves this, and it’s specifically worth checking after any change to your account type or after a broker migrates you to a different execution venue, since supported filling modes aren’t always consistent across a broker’s own account tiers.

Working through it in order

The efficient diagnostic sequence, roughly, is: confirm AutoTrading and connection status first, since those are instant checks; read both logs before assuming anything about the strategy logic itself; verify the time zone your hour filters are actually being evaluated against; confirm whether a volatility or spread filter is correctly vetoing setups rather than malfunctioning; and only after all of that, start questioning whether the pattern itself has stopped setting up, which is a separate and much larger question about regime shift rather than a “my bot is broken” question at all. Most silent EAs aren’t silent because the strategy died. They’re silent because one link in a fairly long mechanical chain — terminal, connection, clock, filter, broker symbol, order type — quietly stopped matching what the code assumed, and the fix is almost always found by working backward through that chain rather than by rewriting the entry logic.

This is worth internalizing precisely because a validated system going quiet triggers the same instinct as a validated system losing money: the urge to intervene immediately, tweak something, and feel like you’ve done something about it. But a strategy that’s been through walk-forward validation and produced a believable win rate wasn’t validated on the assumption that it fires every single day without interruption — plenty of legitimate pattern-based systems have dry stretches built into their normal trade frequency. Confusing “the EA hasn’t opened a trade in three days” with “the strategy is broken” leads to the same premature-intervention trap as confusing a statistically normal losing streak with a dead edge. The discipline is the same in both cases: check the mechanism methodically before you touch the logic, and don’t let silence alone talk you into changing something that was working exactly as designed the last time you checked.