A cTrader protection is only as useful as the part of the platform that continues to run it. Do not assume that every trailing stop, break-even move or multi-target plan survives a disconnect: identify whether it is held by the server, dependent on the app, or implemented by a cBot, then test that exact path on demo.
That distinction matters more than the label beside the checkbox. A stop that exists at the broker side and a rule that needs an open application may look similar before a connection fails. They are not the same operating control.
The current documentation does not support one blanket answer
cTrader's Protections guide says that trailing stop loss, break-even stop loss and multiple take-profit levels are server-side, work across cTrader apps and remain active after a session ends. It describes up to five take-profit levels for partial exits.
But the Trade Watch guide still states that its Advanced take profit and Move stop loss to break even features work only when cTrader is running and online. The same page distinguishes those controls from Server take profit and Server stop loss, which it says remain active when the app is closed or disconnected.
Those two pages cannot be turned into a guarantee about every installation. They may describe different entry paths, versions or stages of a platform transition. The useful conclusion is narrower: inspect the protection that your account actually created, and do not infer persistence from a familiar name.
Sort the protection by where it runs
The first review is architectural, not directional. Record which component owns the condition after the order has been sent.
| Protection path | What the current cTrader documentation says | What to verify before relying on it |
|---|---|---|
| Server stop loss and server take profit | The Trade Watch guide says these levels remain active when the app is closed or disconnected. | Confirm that the position displays the server-held level after creation, then verify it in a controlled disconnect. |
| Trailing stop loss | The Protections guide calls it server-side and says it remains active after a session ends; Trade Watch also says trailing stop loss works when the app is closed or disconnected. | Confirm the trailing condition is attached to the live position and retain the position timeline. |
| Break-even and multiple take profits | The Protections guide describes them as server-side; Trade Watch retains a note that its Advanced take profit and Move stop loss to break even need cTrader online. | Identify the exact control and version, then test the post-disconnect behaviour rather than assuming the two pages mean the same thing. |
| cBot-managed protection | A cBot can implement its own polling, modification or exit logic. That logic depends on the cBot and its execution environment, not on the presence of a platform field. | Review the code path, logs and restart behaviour separately from any server-held order protection. |
The last row is where many operational reviews become vague. A cBot can place a server stop loss and also run additional logic around it. The server-held order protection may persist while the cBot's extra rule does not. Treat those as separate controls with separate evidence.
What the 5.9 API change actually establishes
The cTrader Algo API 5.9 changelog says that July 2026 introduced a server-side Advanced Protection API. It allows a single trade call to declare a stop-loss/take-profit plan, partial and final take profits, and break-even rules; the changelog says the server enforces those conditions instead of an algo polling loop.
That is a useful design change for a cBot author. It does not prove that every older app workflow, every existing cBot or every broker-facing interface uses that API. The changelog itself does not identify the app versions or account configurations that resolve the difference between the two help pages.
For an automated system, write down the answer to a more precise question: “Which order protection was submitted, through which API or interface, and what remained visible after the client disconnected?” A general statement that the bot “has break-even” is not enough to audit the failure path.
Run a disconnect test that leaves evidence
A controlled demo test is more useful than trying to reason from a label. Use an instrument and position size appropriate for a non-production environment, set the protection you need to verify, and preserve the observations.
- Record the platform version, broker or server, account type, symbol and the exact protection entry path.
- Open a demo position with the relevant server stop loss, take profit, trailing stop, break-even or advanced target configuration.
- Capture the position details and the position timeline documented by cTrader, including the visible SL and TP fields.
- Disconnect or close the client in the controlled manner your operating procedure permits, without adding a second exit rule during the test.
- Reconnect, compare the position state and timeline with the recorded configuration, and note any modification, trigger or missing condition.
- Repeat after a platform, broker or cBot deployment change.
Do not force the price path or claim that a test recreates a stressed market. The purpose is smaller and more defensible: establish whether the protection state persists through the particular client interruption you care about.
For the other half of the operational picture, use the cBot restart test. For an account-level control that watches risk separately from one position, see the prop-firm kill-switch test.
A protection is not a fill guarantee
A stop loss is an instruction to close when its trigger conditions are met; it is not a promise that the exit price will equal the level selected. cTrader's Protections guide notes that a break-even stop at the entry price can still produce a small net loss after spread, commission or slippage, and that an offset can be used to seek coverage for those costs.
This is why persistence and execution quality are different questions. A disconnect test can show that a condition survived. It cannot establish future liquidity, slippage, broker handling or the suitability of a trade. Keep those limits visible in a backtest and in a live-operating record.
realbacktesting is a trading-software studio for cTrader built around results traders can inspect rather than simply accept. Its methodology makes data, execution and cost assumptions visible for published backtests. The same habit belongs in automation: retain the exact protection setup, test the interruption path and do not turn a documentation sentence into a promise.
Frequently asked
Does a cTrader stop loss stay active when the app is closed?
The Trade Watch guide says Server stop loss remains active when cTrader is closed or disconnected. Confirm the protection type on your own position and test it on the platform version and broker account you use.
Does cTrader break-even work after a disconnect?
The current cTrader help pages describe this differently. The Protections guide calls break-even server-side, while Trade Watch says its Move stop loss to break even feature requires cTrader to be running and online. Verify the entry path and run a controlled demo test rather than assuming either statement covers your setup.
Can a cBot replace server-held protection?
A cBot can manage an exit rule, but that rule depends on the cBot's own running state unless it has submitted an enforceable server-held protection. Review the cBot logic and the order protection as separate controls.
The stubborn takeaway
A protection you have not classified and tested is a description of intent, not yet an operating safeguard.