An EA that has not opened a trade may be working normally, waiting for its documented conditions. An EA that attempted an order and received a rejection has a different problem. Logs help distinguish these situations, but one red message or an empty chart is not enough to establish the cause.
Use desktop MT5's Experts and Journal tabs alongside the actual positions, orders and account history. Preserve the original evidence before changing settings. The sample messages below are fictional teaching examples; they are not logs from a Quantora account, and they do not justify changing a funded account to force a trade.
Choose the right record for the question
The Experts tab contains messages from running Expert Advisors and indicators. The Journal tab records platform activity, including connection and trade-operation events. A message saying a program initialised proves that it started; it does not prove that all permissions were enabled or that an order was executed.
The account history is the place to reconcile actual deals and position changes. An order request, accepted order, deal and position are distinct records. Check the timestamp convention: desktop journal timestamps use the computer's time zone, while trade-history execution times use the broker server's time zone. Label both before comparing them.
| Question | Primary place to inspect | What it can establish |
|---|---|---|
| Did the program start or explain a filter? | Experts | Program messages it actually emitted |
| Was the platform connected? | Journal | Recorded connection/platform events |
| Was volume really traded? | Trade and History | Accepted orders, deals and current exposure |
Reconstruct one attempted order
Imagine an EA prints at 09:00:00 that it evaluated a fictional EURUSD entry. At 09:00:01 it records a trade-server result of 10014, followed by a message that the proposed volume was 0.015 lots. The broker specification in this exercise permits 0.01 increments. That sequence suggests checking volume normalisation, rather than assuming the signal or network failed.
The next step is to confirm the current minimum, step and maximum for that exact symbol and the input the EA actually used. Do not round a funded order upward simply to remove the error: the adjusted volume changes risk. A developer may need to correct validation. Save the rejected request details and demonstrate the behavior on demo.
Distinguish server return codes from program errors
MetaQuotes documents 10014 as invalid volume, 10016 as invalid stops, 10019 as insufficient money, 10026 as server-side automated-trading restriction and 10027 as client-side automated-trading restriction. These are trade-server return codes. A runtime error from another API, an EA's custom number or a textual status is not necessarily from the same code list.
Read the complete line and its context. An invalid-stop result can involve broker distance rules or an incorrectly placed price; an insufficient-money result calls for margin review, not an automatic deposit. The exact code identifies a category to investigate. It does not identify a safe correction without the symbol, account and requested operation.
Check permissions and strategy filters separately
Review the platform-wide Algo Trading setting, the attached program's own permission and whether the account permits trading. Also verify connection, chart symbol, timeframe and account model. Allowing program execution and allowing automated order placement are different states.
If permissions are available but the Experts output says spread too high or waiting for a new bar, compare the message with the product's documented rules. A filter can intentionally block entries. Do not disable filters or enlarge lots to create activity. If the program does not log its reasoning, ask the developer what diagnostic mode is supported instead of interpreting silence as proof of failure.
A timeout needs reconciliation before a retry
An uncertain transport outcome can differ from a definite rejection. If the request timed out after submission, inspect current positions, pending orders and history before allowing another order. Sending the same request again without checking can duplicate exposure if the original reached the server.
Likewise, after a restart, confirm how the EA discovers its existing positions and pending orders. Magic numbers and ticket records help identify ownership but are not a universal safeguard against duplicate processing. Keep a chronological account of the request, response and observed position state so the developer can trace the transition.
Collect a useful, private support package
- Record terminal build, EA version, broker/server label, exact symbol, timeframe and account mode; provide credentials to nobody.
- Save the relevant Experts and Journal time interval, including messages immediately before and after the error.
- Use the tab's Open command to preserve the dated files. Platform logs and EA logs are stored separately; identify which you are sharing.
- Include a redacted input snapshot and symbol specification, plus the trade result or absence of an accepted deal.
- Remove account identifiers, personal details, passwords, tokens and unrelated private records before sharing externally.
- State which actions were tried and what changed. Change one variable at a time in a controlled demo reproduction rather than restarting repeatedly on live exposure.
Common questions
- Does an empty Experts tab prove that the EA is inactive? No. It may emit few messages, you may be viewing the wrong period, or its conditions may not require action.
- Can I clear logs to fix an error? Clearing the display does not correct the cause; preserve the evidence first.
- Does a green trading button prove that a trade should open? No. Program-level permissions, account restrictions, market conditions and strategy rules still apply.