If the bot stops, your open positions stay exactly where they are, and so do their exits. On Binance Futures, the take-profit is a reduce-only LIMIT order and the stop-loss is a STOP_MARKET order, and both are placed on the exchange the moment the entry fills. They rest on Binance's own order book, not in the bot's memory. If the process dies, they keep waiting for price to reach them, and Binance fills them whether or not anything is watching. What stops is everything that requires a running process: new entries, cleanup, and the Telegram messages that tell you a fill happened.
This article is written from running an autotrader across 500+ Binance USDT-M pairs. It describes what the software actually does, including the parts that are inconvenient, because "what happens if it crashes" is the question every sensible person asks before handing an API key to anything.
Where each order lives once a trade is open
The reassuring answer above depends on one design decision, so it is worth being precise about it. When a signal passes the user's filters, the bot places three things.
The entry is a MARKET order. It fills within moments, which is the point: a signal is time-sensitive and a limit entry that never fills is worse than a small amount of slippage. Once filled, the entry is history — there is nothing left to survive or fail.
The take-profit is a reduce-only LIMIT at the signal's target. Reduce-only means Binance will only ever let it shrink or close the position, never open a new one or flip direction. It is submitted to Binance and sits on the book. If the user has chosen a trailing take-profit instead, it is a TRAILING_STOP_MARKET routed to Binance's algo order endpoint — still on the exchange, still independent of the bot.
The stop-loss is a STOP_MARKET, placed only when the user has a stop configured. The stop distance is defined without leverage, so a 2% stop means a 2% move in price, not a 2% move in your margin.
Both exits carry deterministic client order IDs built from the signal and user, so a retry after a crash cannot accidentally create a second position. Idempotency is enforced at the exchange, which is the only place it can be trusted.
The flow that makes this work
The order of operations matters. The bot waits for the entry fill before sizing the take-profit, because the exit has to match the quantity that actually filled, not the quantity requested. Then it places the take-profit, then the stop. Only after all three are acknowledged does it consider the position "set up".
From that point, information flows the other way. Binance pushes every fill and position change back over the user-data WebSocket stream. The bot does not poll to find out whether your take-profit hit; the exchange tells it. That is also why the bot can be down for a while and catch up: the state of truth was never in the bot.
What keeps working during an outage
Your take-profit keeps working. If price reaches the target, Binance fills the reduce-only LIMIT and the position closes. You will not get the Telegram message about it until the bot is back, but the money is already in your wallet.
Your stop keeps working. Same mechanism. A STOP_MARKET on Binance triggers on Binance.
Liquidation protection is Binance's, not the bot's. The exchange's own margin engine does not care whether your bot is alive.
You can always act manually. Nothing about the bot's setup locks you out of your own account. You can close a position, move a stop, or cancel an order from the Binance app at any moment.
Funding never waits. Funding settlements happen on their schedule regardless. If you are holding a position through an outage, funding is still being paid or received.
What pauses, and why it matters
New entries stop. A signal that fires while the bot is down simply does not get traded. There is no queue that replays it later, and there should not be: a signal from forty minutes ago is not the same trade.
Orphan cleanup pauses. This is the one that needs explaining. When a take-profit fills, the stop for that position is still sitting on the book with nothing to protect. The bot normally notices the position going flat on the user-data stream and cancels that stop immediately. Down, it cannot.
Notifications pause. Fills that happen during the outage are reported when the bot reconnects and reads the account state.
The in-memory position view goes stale. On restart the bot rebuilds it from the exchange, which is the whole reason it can be trusted.
An outage, minute by minute
The timeline above is illustrative, but the sequence is exactly what happens. The only genuinely awkward moment is the orphaned stop: a STOP_MARKET that survives its position.
What is the risk of an orphan? In one-way mode — which is the only mode the bot supports — a stop with no position behind it could, if triggered, open a new position in the opposite direction. That is the reason the bot cancels orphans aggressively when it is running, and the reason the manual checklist below includes looking for them when it is not.
The orphan stop, and how the bot handles it
Here is the actual behaviour, because it is the part most bots get wrong. Every account update from Binance carries a position amount per symbol. When that amount reads zero for a symbol the bot was trading — and the update is not merely a funding-fee event — the bot clears its own record of the position and then cancels every STOP_MARKET it holds for that symbol, on both sides.
If Binance rejects a cancel, the bot logs a warning with the order ID and moves on rather than retrying blindly. If the cancel throws, it logs an error. Either way the orphan is reported, not hidden.
When the bot restarts after an outage, it reads open positions and open orders from the exchange first. A stop with no position is visible in that read, and the same cleanup runs. So the orphan window is the length of the outage, not longer.
What to check yourself if the bot is unreachable
Two tabs on Binance Futures answer every question in this article: Positions and Open Orders.
For each open position, you want to see one reduce-only exit and — if you configured one — one STOP_MARKET on the opposite side. If you see a stop with no matching position, that is an orphan; cancel it. If a position has no stop because you never set one, that was true before the outage too, and the outage did not change it.
Then look at your margin ratio. If it was comfortable before, it is comfortable now; the bot's absence does not change your leverage.
The whole check takes a couple of minutes for a normal account. If it takes half an hour, the problem is not the outage — it is that you have more simultaneous positions than you can reason about, and the max-positions setting exists for that.
Everything you can do by hand
Manual intervention is allowed at any time, running or not. You can close at market, move or add a stop, cancel an orphan, or reduce size. The one thing to know: with "combine" stops on, the bot sizes its stop against the whole position; otherwise only against its own quantity. So if you manually added to a bot-opened position, check which mode you are in before assuming the resting stop covers the whole thing. The guide on setting a stop-loss in crypto covers the sizing arithmetic.
Your exposure is decided by two settings you chose earlier
An outage does not create risk. It reveals the risk you were already carrying.
If you set a stop and sized positions sensibly, an outage is boring: your exits are on the exchange, and the worst case is a missed entry. If you set no stop and sized large, the outage is not the problem — the position was always exposed, and the bot being alive would not have changed that, because the bot only places the stop you configure.
That is why the two settings worth reviewing today, before any outage, are the stop and the maximum number of simultaneous positions. A burst of signals can otherwise open more positions than your wallet should carry — and the bot enforces the limit you set, not one it guesses.
What the bot cannot do, on purpose
The API key the bot uses is Futures-enabled and cannot withdraw. Running or stopped, it has no path to move funds off your account. The guide to connecting a bot to a Binance API key safely walks through the permissions, and the short version is that the only permission a trading bot needs is the one to trade.
There is also a deliberate limit on what the bot will do without you. It does not average down, it does not widen a stop, and it does not reopen a trade that stopped out. A bot-opened trade closes on stop or target, and that is the whole list.
How to see whether any of this is true
Every claim above is about mechanism, and mechanism shows up in outcomes. The live performance page is regenerated hourly from the same trade database the bot writes to when it sends a signal, with expired signals counted against the hit rate. If exits routinely failed during outages, it would show as losses and expirations, not as marketing.
For the broader question of whether a bot is worth running at all, are crypto trading bots worth it is the honest version, and is HafizeBot legit collects the evidence rather than the claims. If you want to ask the team directly, the bot itself answers at t.me/hafizebot.
Frequently asked questions
If the bot crashes, will my open position be closed? No. Nothing closes a position except a fill. Your position stays open, and the take-profit and stop orders resting on Binance keep working exactly as before. What stops is new entries and notifications.
Do the take-profit and stop-loss orders survive an outage? Yes. Both are placed on Binance's order book when the entry fills — a reduce-only LIMIT and a STOP_MARKET. They are exchange orders, not bot orders, and Binance fills them whether or not the bot is running.
What is an orphan stop and is it dangerous? An orphan is a stop order whose position has already closed, usually because the take-profit filled first. In one-way mode a triggered orphan could open a new position in the opposite direction. The bot cancels orphans automatically when running; during an outage, check the Open Orders tab and cancel any stop with no position behind it.
Will the bot enter signals it missed once it restarts? No. A signal that fired during the outage is not replayed. A trade from forty minutes ago is a different trade, and entering it late would be worse than skipping it.
Can the bot withdraw my funds while it is down or running? No. The API key is Futures-enabled only and has no withdrawal permission. There is no state in which the bot can move funds off your account.
What should I check first if I cannot reach the bot? The Positions and Open Orders tabs on Binance Futures. Confirm each position has its exit orders, cancel any orphaned stop, and glance at your margin ratio. It takes about two minutes.
Closing note
The honest summary is that an outage is only dangerous if the position was already dangerous. Set a stop, cap your simultaneous positions, and the bot going quiet for an hour costs you a missed signal, nothing more.
None of this is investment advice. Cryptocurrency futures carry a high risk of loss; trade only with money you can afford to lose.