MT5 Pending Order Expiry: Why Your Choices Can Differ

Published November 9, 2026 · View Markdown

The same pending-order template can offer a deadline on one MT5 symbol and a disabled expiration field on another. Start with the symbol and server rules. A date that is convenient for your strategy is not automatically an allowed order lifetime.

For automated trading, the practical question is how long an unfilled instruction remains eligible to become a trade. In an AlgoWay workflow, review this at the MT5 account alongside the broker checks described in the AlgoWay guide to MT5 stop-distance rules. This article explains MT5 expiration behavior; it does not assume that a particular connector exposes every MT5 lifetime option.

Separate the allowed choices from the requested choice

MetaQuotes documents symbol-specific pending-order expiration permissions. A symbol can allow several modes. The public MQL5 property SYMBOL_EXPIRATION_MODE reports a combination of flags, not the lifetime of one individual order.

The flags are GTC = 1, current day = 2, specified date and time = 4, and specified day = 8. For example, a hypothetical value of 5 combines 1 and 4: GTC and a specified timestamp are allowed. It does not mean “five days,” nor does it include day-only expiry. An order still needs one permitted lifetime choice.

In the terminal, check the exact symbol in the pending-order dialog. The MT5 trading help states that an inactive Expiration field means changing it is disabled on the server. It also describes changing the expiration of an existing pending order through its modification dialog. A disabled control is therefore not proof that your installation is broken.

An exact deadline is different from a specified day

The MQL5 order-lifetime reference distinguishes these requests:

• GTC: good till canceled, subject to the symbol's additional GTC rules.
• Day: valid for the current trading day.
• Specified: valid until the requested expiration timestamp.
• Specified day: the MQL5 ORDER_TIME_SPECIFIED_DAY definition uses 23:59:59 of that date. If that falls outside a trading session, expiry occurs at the nearest trading time.

Do not substitute a day-based setting for a strategy that requires an exact intraday deadline. Suppose a setup is valid from 10:00 until 10:30. Keeping it active for the trading day changes the strategy: it can become eligible to trade long after the setup was meant to expire.

MetaQuotes' terminal help uses different midnight wording for its date-only choice. For an automated MQL5 request, use the API definition above, then confirm the accepted expiration shown for the actual order. Ask the broker to clarify the applicable clock and session boundary if the display is ambiguous. Do not infer an exact deadline from a calendar label alone.

GTC has a second setting worth checking

The MT5 symbol-property reference documents three GTC policies. Persistent GTC keeps pending orders and protective Stop Loss/Take Profit levels until explicitly canceled. Daily mode deletes pending orders and those protective levels at the end of the trading day. Daily-excluding-stops mode deletes pending orders but preserves SL/TP levels when the trading day changes.

These are symbol policies, not three outcomes to choose after an order disappears. A strategy intending to carry a pending entry overnight must first establish which policy applies. If daily cleanup can remove protective levels, reviewing only the pending-entry list misses a separate exposure problem on open positions.

Trace one missing order before renewing it

Consider an illustrative pending buy order that is no longer active after a session boundary. There are at least three materially different questions to answer: did it expire, did someone cancel it, or did it execute? An empty active-order list cannot answer all three.

1. Record the accepted order's lifetime and deadline, rather than only the value your strategy intended to send.
2. Check the order history, associated deals and current positions. Use the distinction between MT5 orders, deals and positions to reconcile what actually happened.
3. If it expired without executing, decide whether the original setup remains valid. A fresh order should be a deliberate strategy decision.
4. If it executed, account for the resulting exposure before submitting anything else. If the state is uncertain, resolve that uncertainty before a retry.

This is a different issue from IOC and FOK partial-fill rules. Those govern immediate execution and available volume; expiration governs how long an eligible pending instruction can remain active.

For a demo check, record the symbol, accepted lifetime, displayed deadline and eventual history state around the relevant boundary. That is a proposed verification procedure, not a test result. The objective is simple: an old setup should not survive merely because the automation remembered its price and forgot its deadline.