Engineering note · Entry diagnosis
Your MT5 EA Missed an Entry: Find the First Missing Decision
A chart shows the entry you expected, but the MT5 EA did nothing. That symptom does not yet identify a faulty signal formula. Start with one named bar and find the first decision that differs from the written rule. Changing several filters at once destroys that evidence.
- 01Freeze one bar
- 02Record the inputs read
- 03Name the first blocked stage
- 04Retest with an unchanged control
A marker and an entry decision have different timing
Save the exact symbol, timeframe, broker feed, input set, EA revision and server timestamp. State whether the rule reads the open bar or the last completed bar. An indicator plotted on a completed candle can look obvious later while the values available to the EA earlier were different.
Keep the bar timestamp alongside the evaluation timestamp. A closed-bar rule evaluated on the first tick of the following bar should retain both identities. Do not shift either timestamp until the chart and the trace appear to agree.
Trace the first divergence, not every possible setting
Give each stage one observable result: input ready or unavailable; signal true or false; permission allowed or blocked with its reason; request sent or absent. If an indicator buffer was unavailable, a later false signal is not a valid measurement. If the signal was true but the session gate rejected it, changing the crossover is the wrong repair.
Check the event model too. MQL5 handles events sequentially. A new NewTick event is not added when one is already queued or being processed. A slow handler therefore cannot be assumed to inspect every market tick. This is a documented event boundary, not proof that it caused this particular missed entry.
The terminal Algo Trading setting does not stop OnTick processing. It prohibits sending trade requests. Keep calculation evidence separate from permission to execute, then inspect the trade result separately from the request call.
- Data: bar identity, buffer readiness and values actually read.
- Signal: frozen comparison and chosen bar index.
- Gate: first rejected session, spread, exposure or permission rule.
- Request: whether a request exists and its recorded result.
Keep the legitimate no-trade case
A repair is not accepted merely because the previously missing trade now appears. Use a second case where the same signal must stay blocked under the unchanged rules. Otherwise disabling a session filter can look like a successful repair while breaking the strategy.
For an intermittent failure, preserve the environment and repeat the exact incident where possible. A historical test without the original tick sequence cannot establish the cause of a live intrabar event. Record that limitation instead of presenting the replay as equivalent.
Three acceptance checks
Proposed tests, not executed customer results. Record actual outcomes separately.
Qualifying closed bar
Input: Use a frozen completed bar, ready input buffers and all declared gates allowed.
Expected: The trace identifies the bar and one qualifying entry decision. Request outcome is reported separately.
Legitimate gate rejection
Input: Use a qualifying signal with a declared session or spread gate blocked.
Expected: No request is sent. The unchanged gate and its recorded reason explain the skip.
Unavailable input
Input: Evaluate before the required indicator buffer is ready.
Expected: The trace records unavailable input rather than inventing a false signal or entering with stale values.
Sources and related guides
Start with your own rules
Use the free Rule Check to name the entry timing and the no-trade rules before requesting a repair. Do not upload credentials.
Write the expected decision →