EA Log Design: Make Incidents Reproducible Later

Conclusion: An EA Without Logs Can't Be Investigated After an Incident

Here is the conclusion up front. An EA should write, at minimum, one line each for three things: "the values used for the decision," "the reason it did not enter," and "the result of the fill." With these three, you can reconstruct an unexpected trade, or the fact that "nothing happened," after the fact. Without them, whether you took a loss or sat at zero trades, you cannot separate whether the cause was the EA's logic, the market, or the broker.

We develop EAs ourselves, and we have had cases where logs saved us and cases where the logs were insufficient and we never found the cause. This article lays out what a "good log" looks like from the perspective of the person running the EA.

Why You Need Three Types of Logs

A single EA decision roughly follows this flow: "calculate values → evaluate conditions → place an order → get filled." To pinpoint at which stage things deviated from expectations, you need a record of each stage.

Decision Values: Without Numbers, You Can't Tell It From a Fluke

A log that only says "buy signal triggered" is of little use. Unless you know how far the indicator value was from the threshold at that moment, you can't tell whether the condition was barely met or clearly met. Always record which bar (the closed bar's time) the decision was based on as well.

Skip Reasons: The Most Often Omitted and the Most Important Log

Most EAs only log when they enter. Yet the most common question during live operation is "it never enters." If the skip reason is in the log, you can check whether the skip was by design, or caused by a configuration mistake or a server time offset.

Our MEGAMAX DONCHIAN has zero trades as of November 11, 2026, in forward testing on an Exness demo account. We have not yet confirmed the reason for the skips ourselves, and we won't speculate about it here. Still, whether a skip-reason log exists makes a big difference in how much effort it takes to check in a situation like this. Zero trades does not mean poor performance, but until we read the log, we can't call it a "normal skip" either.

Fills: Record What Happened Outside the EA

Whether an order was rejected, or filled with large slippage, is a separate issue from the EA's logic. If you keep the return code and the fill price, you can separate EA problems from broker or connection problems.

What to Put on One Line: Writing Examples

We condense each decision into one line, in a fixed format that is easy to search later.

[EVAL] bar=2026.11.10 14:00 sig=BUY val=1.234 th=1.200 spread=18 -> ENTRY
[SKIP] bar=2026.11.10 15:00 reason=SPREAD spread=45 max=30
[FILL] ticket=123456 req=152.340 fill=152.346 slip=6 ret=10009

Key points when writing:

• Start with a type tag (EVAL / SKIP / FILL) so grep or search can pick the lines up
• Write the time of the "closed bar used for the decision" (assume it is server time)
• Write reasons as fixed codes, not sentences (SPREAD, TIME, POSITION, etc.)
• Don't log on every tick; log only at the moment of decision

Logging on every tick makes the log huge in a short time, strains disk space, and buries the lines that matter. The basic rule is "once, when the bar closes."

Checking Procedure for Those Running the EA

If you run an EA, checking in this order gets you to the cause faster.

1. In MT5's "Experts" tab, confirm the EA is writing its own logs
2. Find the EVAL line at the time of the unexpected trade and look at the decision values and the threshold
3. For periods with no entries, look at the SKIP lines and count which reasons are most frequent
4. On the FILL line, check the gap between requested and fill price, and the return code
5. Cross-check the times against the "History" tab (the broker-side record)

For reviewing settings, see EA Setup Guide. For building an always-on environment, see VPS Information.

Limits and Cautions

Logs are not a cure-all. To be honest about it:

• You can't know what isn't written. Events the developer didn't anticipate are never recorded in the first place.
• A log isn't necessarily correct. If the logging code itself has a bug, wrong values get recorded.
• Logs don't tell you whether the market call was good. A log shows whether the EA "behaved as specified," not whether that specification wins.
• Logging too much also causes incidents. Huge logs eat up storage and make it easier for readers to miss things.
• Logs mean different things in backtests, demo accounts, and live accounts. The tester doesn't reproduce slippage or rejections the way real trading does, so keep the environment difference in mind when comparing fill logs.

Summary

• Write one line each for three types: "decision values," "skip reasons," and "fills"
• Skip-reason logs are the most often omitted, and the most useful when investigating why "it doesn't trade"
• Fixing tags and reason codes lets you search and count later
• Output once per closed bar, not on every tick
• Logs only tell you whether it "behaved as specified"; whether it wins takes separate validation

For more MT5 operations know-how, see EA & MT5 Know-How.