What happens to your open position when your automation goes down

There are two ways software can give you a stop loss, they look identical on a screen, and they behave completely differently when that software stops running.

A resting order is a real order sitting at the broker, working, visible in the broker's own platform, with a time in force that keeps it alive across sessions. Nothing on the automation side needs to be running for it to trigger. The broker fills it because it is an order they are holding, exactly like one you placed by hand.

A synthetic stop is a condition some piece of software is watching. It has no existence at the broker. When price reaches the level, the software notices and sends an order. If the software is not running, nothing notices, and nothing is sent.

We place protective legs as real orders at the broker, attached to the entry, with an explicit good-till-cancelled time in force. They are resting orders at the venue. They do not need us.

This is worth checking with any vendor you use, and the question that gets a straight answer is not "do you support stop losses". It is: if your service stops right now, is my stop visible in my broker's own platform? Log in and look. Either it is there or it is not, and the answer is not a matter of opinion.

Why attaching them to the entry matters

There is a second decision hiding behind the first. Protective orders can be sent with the entry, as one instruction the broker expands into an entry plus its brackets, or they can be sent afterwards once the entry is confirmed filled.

The second approach creates a window. Between the fill and the protection landing, you have a live position with nothing behind it, and that window is precisely when a fast market and a software failure are most likely to coincide, because the same volatility causes both. Sending the whole structure as one instruction closes the window: if the entry exists, the brackets exist, because the broker created them together.

The brackets are also linked at the broker rather than in our software. When one side fills the broker cancels the other. That cancellation does not depend on us being connected either.

"My automation went down" covers four quite different failures. They have different blast radii, and knowing which one you are in tells you what to do.

The pattern is the one that should be reassuring: the layer that protects you is the layer furthest from the parts most likely to break. Your laptop, your connection and the routing service are all upstream of a resting order, and none of them can revoke one.

Being honest about this is more useful than a reassurance. There are moments where a failure does reach you, and they are all short, specific, and worth designing around.

Between sending an order and knowing what happened to it

If a request to the broker times out, you have learned nothing about whether the order landed. It may have been accepted a moment before the connection dropped. This is the one genuinely ambiguous state in order routing, and the wrong reflex is to send it again, because that is how one intended order becomes two real positions.

The correct handling is to stop, record the request as unresolved, and answer the question by reading the broker's own order list, which is the only place the truth exists. That is what we do, and it is why a mutating order call is never retried automatically after a timeout.

While a change to a working order is in flight

Moving a stop is not instant. You ask, the broker confirms, and between those two moments the old value is still the one that would fill. Software that shows you the new number before the broker has confirmed it is lying to you in the most expensive possible way. The value you see should change when the broker agrees, not when you click.

A position that never had protection attached

An entry sent without brackets, a position built up by hand, a leg that was cancelled and not replaced: these are unprotected by construction, and no recovery mechanism invents a stop you never asked for. If you are going to be away from the screen, the question is not whether the automation is reliable. It is whether there is a resting stop, right now, for every position you hold.

That last one is worth checking rather than assuming, and it is one of the things manual controls exist for: seeing which positions have protection standing behind them and putting one on the ones that do not.

Recovery is where good systems and bad systems diverge most sharply, because the naive approach looks like it works. The naive approach is to reconnect and carry on from what you remembered. What you remembered is now potentially wrong, and acting on it is worse than having been offline.

1. Reconnect, with a backoff that gets slower rather than faster. A redial loop is how a brief outage becomes a rate-limit lockout that lasts an hour.
2. Ask the broker what it actually has, rather than replaying what we last saw. The feed re-sends a full picture on reconnect, and the broker restates the events we may have missed while we were gone.
3. Reconcile every order we were unsure about against that picture. A unique match means the outcome is recorded from broker truth. No match means the order never landed, and it is failed honestly rather than left hanging.
4. Refuse to guess when the answer is ambiguous. If two broker orders could plausibly be the one in question, nothing is terminalised. It stays flagged for a human, because a wrong resolution here writes a fiction into your trade history.
5. Never revise something already final. A filled order is filled. Recovery can complete an unknown story; it cannot rewrite a finished one.

Sessions expire even when nothing is broken

One quiet failure mode deserves a mention because it does not look like an outage. Broker sessions have a lifetime and have to be renewed. If a renewal is missed, the software is running, the dashboard is up, and nothing can actually be sent. The defence is to renew ahead of expiry rather than on failure, to keep renewing across restarts rather than relying on a timer inside a process that may not survive, and to say so plainly when a connection has genuinely gone stale rather than showing a healthy screen over a dead session.

The trap in the other direction is treating a successful renewal as proof of health. It proves the credential was accepted. It does not prove the account can still trade, which is a separate fact that only a real call to the broker can establish.

When it is actually happening, the useful thing is a short sequence you have already decided on, because you will not be at your most analytical.

1. Look at the broker's own platform, not at the automation. It is the source of truth for what you hold and what is working. Have the login on your phone before you need it.
2. Establish two facts: what your position actually is, and whether a protective order is actually standing. Everything else can wait.
3. If there is no protection, put one on, from wherever you can. A stop placed by hand in the broker platform is worth more than a better one you cannot reach.
4. Do not re-fire the alert. The original may have landed. Re-firing is how you end up with double the position while trying to make yourself safer.
5. When it comes back, retry the failed order from the queue rather than from the chart. A retry knows it is a retry. A new alert does not.
6. Afterwards, read the order timeline. Broker-side timestamps tell you what actually happened and in what order, which is the only way to know whether to change anything.

The preparation that makes all of this easy is unglamorous and takes an afternoon: know your broker platform login, know how to flatten from it, and test that you can do both from your phone on a day when it does not matter.

• If you run several accounts, rehearse the way out as well as the way in. One signal fanning out to many accounts is only safe if closing them is also one action, which is what the trade copier page covers.
• If the failure you are worried about is the order that never should have been sent twice, that is a different problem with a different fix.
• If the outage was your broker refusing requests rather than anything breaking, start with the rate-limit guide.