An accepted Stop Loss or Take Profit is held on the broker’s server, so closing your local terminal does not remove it. First confirm the account, order and accepted level. Server storage does not guarantee execution or a selected fill price; local Expert Advisors and the terminal’s built-in trailing stop have different requirements.

The broker server versus your terminal — where the order really lives

The important distinction is whether the broker’s server holds an accepted instruction or your terminal must calculate and submit it. A click sends a request; it does not prove acceptance. Check the response and current order or position state before relying on an SL, TP or pending order.

Closing MetaTrader leaves already accepted server instructions in place. It also stops functions running only in that local terminal. Check each instruction’s status and contract rules rather than treating server storage as a safety guarantee. The separate guide explains market, limit and stop orders.

No reply does not reveal the recorded stop loss

First establish which instruction the server actually holds. Whether the laptop is running is a separate question.

Scroll sideways to see the full diagram

No reply does not reveal the recorded stop lossOur model has two possible server states after an attempted Stop Loss change from 1.0900 to 1.0950. Neither version has an observed local reply. In A the server accepted the change and holds SL 1.0950. In B it did not accept the change, leaving SL 1.0900. The shared symptom cannot distinguish them. A current reading of the correct, still-open position after reconnection and server synchronization resolves the state at that moment. This is neither a complete catalogue of real states nor an assessment of fill price.ONE SYMPTOM, TWO STATESOur model after an SL change attempt.Requested change: 1.0900 → 1.0950Local symptom: no reply observedVersion AChange acceptedSL: 1.0950Version BUnchangedSL: 1.0900After connection and synchronization:read this position's current state.An old data copy cannot resolve it.No reply ≠ proof of rejection

Assumptions: Our information model contains two invented versions of a completed change attempt. The correct position remains open, its account and identifier are known, and nobody else changes its SL afterward. Levels are USD per EUR. In neither version did the observer receive a reply; we assign no probabilities. The resolving reading comes from the server after synchronization, rather than an old copy.

In A the server recorded 1.0950 but the observer received no reply. In B the change was not accepted and 1.0900 remains. The local symptom is the same; the server state differs. “I saw no reply” therefore establishes neither rejection nor acceptance.

Before another decision, check the account, position identifier, connection and completed synchronization. Read the correct position's current state. In our model a new synchronized reading of 1.0950 selects A; 1.0900 selects B. In a real system also check whether the position still exists, the request is still being processed or another change occurred. The diagram deliberately omits those additional states.

OrderModify documents level modifications and the function result. That differs from our model's missing observed reply. OrderSelect warns that previously retrieved properties are copied and can become stale. Reading an old local copy again does not replace server synchronization. The example establishes neither an automatic retry rule nor the SL's future fill price.

The same missing reply fits two different recorded SL levels.

What works with MT4 closed — stop-loss, take-profit, pending orders

Accepted SL, TP and pending orders are handled on the server rather than requiring your local MT4 terminal to remain open. Buy limit, sell limit, buy stop and sell stop have different trigger and execution rules. Server handling does not mean every instruction will necessarily fill: validity, expiry, price conditions and the execution arrangement still matter.

A confirmed server-held SL remains relevant when the local platform closes. A gap is one execution risk, not the only possible exception: the instruction’s status, instrument and execution arrangement also matter. Do not equate an accepted level with a guaranteed closure or exact fill.

What stops working — Expert Advisor, trailing stop, alerts, scripts

An Expert Advisor runs in its attached terminal and responds to the events its code handles, such as ticks or timers. It need not trade on every tick, and a busy handler may not receive every subsequent NewTick event. Closing that terminal unloads the local EA. Losing a connection is different: code can remain loaded, but current quotes and accepted server operations cannot be assumed. A separately running remote copy is unaffected by closing your laptop. The Expert Advisors guide explains how to inspect its permissions and behaviour.

MT4’s built-in trailing stop runs in the client terminal. Once its profit-distance condition is met, it can request an SL at that distance; later favourable changes can generate further requests. Closing that terminal stops its calculation. Only a level already accepted on the server remains. An enabled trailing stop may not yet have placed any SL. See how trailing stops work; local alerts and scripts likewise depend on their configured runtime.

An example: Marek leaves a position open overnight

In a hypothetical example, Marek opens EUR/USD long at 1.0865 and confirms SL 1.0810 and TP 1.0920 on the server. He enables a trailing distance of forty pips and attaches a local Expert Advisor. On a five-decimal EUR/USD quote, forty pips correspond to 400 platform points. At eleven he closes the local terminal. These levels and timing are illustrative; the trailing setting specifies distance, not a forty-pip modification step.

The confirmed server levels remain after the local terminal closes, subject to their execution rules. With a forty-pip trailing distance, Bid 1.0910 would put the long 45 pips above its 1.0865 entry and allow an SL request at 1.0870. If the server accepted that level before shutdown, it would replace 1.0810. Merely rising to 1.0880 would leave only 15 pips of profit, below the activation distance. Closing the local terminal stops its EA and trailing calculations; accepted server instructions remain subject to execution conditions.

Nuances worth knowing — slippage, gaps and a server-side trailing stop

An ordinary SL does not guarantee either the chosen fill price or unconditional completion. A gap can lead to a different execution price, and the arrangement may permit rejection or other execution constraints. If a broker offers a guaranteed-stop product, verify that specific contract’s instruments, charges and conditions separately; do not infer it from an ordinary MetaTrader SL.

Distinguish MetaTrader’s built-in local trailing stop from any separately documented broker-side trailing service. Confirm the actual platform, account and feature specification before relying on operation with the terminal closed. MT4 and MT5 share this broad server-versus-local distinction, while their order and position-accounting details differ.

What a VPS is actually for

A general-purpose VPS can run a desktop terminal independently of your laptop; the process, connection and permissions still need monitoring. MetaQuotes Virtual Hosting instead migrates a selected environment without a normal remote Windows desktop. Its MT4 rules forbid DLL calls and script migration, allow trading in the virtual terminal and disable local autotrading during migration to avoid duplicate robots. A later local button is not a remote stop command. Verify the remote journal and actual programme, rather than assuming every local setting was copied.

An accepted ordinary SL/TP does not need a personal VPS just to remain on the broker server. Remote computing serves additional logic or monitoring; it does not change the order’s fill guarantee. In a hypothetical single-position model, entry is 1.1050 and two accepted SL changes are 1.1030 and 1.1000. If the latter is accepted last, the final stop is 50 pips below entry; reversing the acceptance order leaves 20 pips. Both requests may succeed while the final state differs. Assume no other changes and valid broker distances: this is an ordering model, not a prediction of fill price. Agree which process owns changes and reread the final state. See VPS and broker latency and the platforms section.

What to do tomorrow

  1. Identify the actual protection. On demo, inspect the current account and position identifier, accepted SL/TP and any local trailing or hidden-stop rule. A trailing setting may not have placed its first SL; a drawn line is not a server instruction. If both are used, confirm the latest accepted SL rather than assuming an initial and trailed stop coexist.
  2. Observe the difference on demo. Confirm the SL and TP, record the relevant position identifier and trailing state, then close the local terminal. Reconnect and synchronize before reading the current state. Server-side events may have executed or changed the position while you were away, so unchanged values are not a guaranteed test outcome.
  3. Assess the runtime you need. List programmes that must act while the laptop is off. Compare a monitored VPS with your existing runtime and verify migration and permissions for the chosen service. An EA in the list alone does not prove that a paid VPS is necessary.
  4. Plan a gap scenario before holding through closure. Specify the instrument, position and hypothetical adverse fill. Review the broker’s execution terms and size the position within your plan without assuming an SL must execute or cap the loss at its displayed level.