MT5 Strategy Tester Execution Delay: What It Changes

A backtest can use the same price history and the same trading rules yet produce different trades when a request reaches execution later. MT5's execution-delay setting lets you investigate that sensitivity. It changes simulated request timing; it does not turn a historical run into a measurement of your live automation.

This matters when reviewing an automated trading strategy before connecting its signals to an account. For an AlgoWay MT5 workflow, keep the strategy test and the live delivery check separate. A delay entered in the tester is an assumption about the simulation, not an observed TradingView-to-MT5 delivery time.

The setting delays requests, not the price history

MetaTrader's Strategy Tester execution documentation describes a delay between an EA's trade request and its execution. Prices can move in that interval. EA operations such as order placement and changes to stop levels are affected.

For pending orders, the documented distinction is specific: the delay applies to placement, not the later execution of an already placed order. That later step takes place on the server. This does not promise an exact live fill price or model every source of execution risk.

Keep this setting separate from real versus generated ticks. One question is which price events the test sees. The other is when a trade request is acted upon. Changing both at once makes any resulting difference harder to explain.

No delay, fixed delay, or random delay?

The official help offers three choices. No Delay is the idealized baseline. Fixed Delay uses a selected or custom interval; MT5 can also use its measured server ping. Random Delay draws 0–8 seconds with 90% probability and 9–18 seconds with 10% probability. Treat that distribution as a stress scenario, not your broker's measured latency profile.

A useful first comparison is a fixed-delay run against a no-delay run. The assumption is explicit, which makes the first changed trade easier to investigate. Random delay can come afterward, once you know how the strategy responds to a known interval.

Read the sequence before blaming the final balance

Imagine an EA deciding to buy at time T. During an illustrative half-second delay, the available quote rises. A later purchase could then have a worse entry, subject to the simulated order and execution rules. If the quote falls instead, the entry could improve. Delay is not a fixed fee deducted from every trade.

Now imagine the EA wants to place a pending order. Ask whether the order had actually been placed before the relevant price event. A price crossing that occurred while the placement request was still waiting is a different story from an order already resting when price arrived. Do not add the same network-delay assumption to both stages merely because both appear in the trade history.

These are reasoning examples, not results from tests we ran. Their purpose is to show which timestamps and order states deserve attention. A later entry can also change the position size, exit opportunity or eligibility for the next trade under your strategy's rules. By the end of a long test, the balance difference may contain many consequences of one early disagreement.

A controlled comparison you can repeat

1. Freeze the strategy. Record the EA version, inputs, symbol, dates, timeframe, deposit, leverage, costs and tick mode. Save the initial report.
2. Set a stated delay assumption. Choose a fixed interval relevant to the question you want to test. Label an illustrative value as hypothetical; do not describe it as measured ping or live order latency.
3. Change only that setting. Run the same historical period again. Compare order and deal details as well as aggregate profit and drawdown.
4. Find the first divergence. Identify the initial request whose timing, outcome or price differs. Check the surrounding quotes and any later order or stop changes before explaining the rest of the run.
5. Inspect failure handling. Look for rejected requests, repeated entries, missing exits or state changes in the tester journal. Confirm what the EA actually did rather than assuming every requested operation succeeded.
6. Keep the result in its proper category. Record it as sensitivity to an assumed execution delay. Separately reserve later historical data or run a demo workflow when those answer the next question.

For that last step, the MT5 forward-testing guide distinguishes a historical holdout from observation on a running account.

What a reassuring result still leaves unanswered

If two delay settings produce nearly identical results, the narrow finding is that this EA, dataset and configuration were insensitive to those settings. It does not establish that a webhook was delivered, that a terminal stayed connected, or that a broker filled the intended quantity.

For a separate demo automation check, trace one signal through the available alert, delivery and account records. Compare the requested symbol, direction, quantity and protection with the resulting order and position. Keep clocks and timezones consistent when comparing timestamps. Do not turn a single successful event into a general speed claim.

A useful test note names the EA, period, tick mode, delay assumption and first changed request. “The delayed run made less money” is an observation. Explaining which operation changed is the part you can act on.