Placing an order is the easy half. A signal copier that only places orders has automated the part you could have done yourself in ninety seconds.
The hard half is the next six hours, when nobody is looking at the screen, and a position needs its stop moved, its targets adjusted, and someone to notice when the broker closes it. That is a monitoring problem, and monitoring problems are where trading software quietly fails.
This is how ours is built. I am writing it out because "we monitor your trades 24/7" is a sentence every product in this category puts on its homepage, and it means nothing without the mechanics underneath.
The primary path: a streaming connection
The main way we learn what your account is doing is a persistent streaming connection to the broker. Orders filling, positions opening and closing, stops being hit, balance changing: these arrive as events, in near real time, without us asking.
One constraint shapes everything about how this is built. A broker account permits exactly one streaming connection at a time. Open a second and you get connection churn, rate limiting, and eventually silent drops on the feed that matters. So there is one connection per account, shared by everything that needs it, and anything that opens a temporary connection for a one-off read has to close it properly or it competes with the live one.
That sounds like a detail. It is the reason a lot of trading tools become unreliable at exactly the moment you add a second account.
Why one path is not enough
Streaming connections drop. The broker restarts something. A network path degrades. A provider has a regional incident. During any of those, events do not queue politely and arrive later. They are simply gone.
If the stream were the only thing telling us your position closed, a dropped connection would mean a trade that closed at the broker twenty minutes ago is still shown as open, still being managed, with breakeven logic operating on a position that no longer exists.
So the stream is not the only thing.
The position watchdog
The watchdog runs on its own schedule and asks a different question: it goes and reads the account's actual open positions from the broker and compares them against what we believe is open.
Anything we think is open that the broker does not have is investigated and reconciled. This catches every closure the stream missed, without depending on the stream being healthy.
The watchdog is deliberately boring. It does not optimise, it does not batch aggressively, it just goes and looks. Redundant systems should be simple, because a clever fallback that fails in a correlated way with the primary is not a fallback.
The rule underneath all of it
Here is the principle that governs every one of these paths, and it is the single most important thing in this article.
A read that fails is not a read that returned nothing.
If we ask the broker for your open positions and the request errors, times out, or comes back malformed, the answer is "we do not know". It is not "you have no positions".
Treating those two as the same thing is the most common and most expensive class of bug in software that talks to a broker, and it is expensive because of what happens next. Code that concludes a position is gone will finalise the trade, write down a result, and stop managing it. Meanwhile the position is still live at the broker, with no stop management, no targets, and nobody watching.
So a failed read stops the decision rather than feeding it. Anything that cannot be verified fails closed.
The same rule applies to writes. If we tell the broker to move a stop and cannot confirm it landed, the stop has not moved as far as our records are concerned. Recording an unconfirmed success is how you end up with a dashboard showing protection that does not exist.
Ordering, and why it needs locks
Several things can want to act on the same trade at once. A take-profit level is reached while a follow-up message arrives changing the stop, while the watchdog is mid-reconciliation.
Left alone, those race. Two processes read the same state, both decide to act, and the second overwrites the first. The outcomes are bad in specific ways: a stop moved backwards, a target re-applied after being deliberately changed, a position closed twice.
Every operation that changes a trade takes a lock on that trade first. Work on a trade is serialised. Different trades run in parallel, so this costs nothing in throughput, and within one trade things happen in a defined order.
One exception is deliberate. A kill-switch sweep that closes every position on an account can take a while, and holding the lock for its whole duration would block everything else. So the halt flag is set inside the lock, the lock is released, and the sweep runs outside it. Setting the flag is the part that must be atomic. The sweep is not.
What this means for you
Concretely: if the broker closes your position while your connection is having a bad afternoon, the watchdog finds it. If a stop modification is refused, the trade is left as it was rather than left in an undefined state. If two things try to manage the same trade at once, they take turns. And if we cannot verify something, we do not write it down as though we could.
None of that is glamorous and none of it is on the pricing page. It is the difference between a tool that works when conditions are normal and one you can leave running overnight.
Related: how signal parsing and execution fit together, and what breakeven automation actually does.
Start a free 7-day trial at telegramtometatrader.com.
