Exchange Outages: How to Protect a Live Trading Bot

Exchange outage risk is the one your backtest cannot see. Historical data has no gaps where the exchange went down for forty minutes. It has no candles where the order book was frozen while price moved 6% elsewhere. Yet every live algorithmic trader eventually meets that moment. The strategy is correct. The position is open. The connection is dead. This post covers the four ways an exchange fails you and the rules that keep a bot safe when it does.

What Is Exchange Outage Risk?

Exchange outage risk is the chance that your venue fails you while you hold a position. It stops accepting orders, stops sending data, or sends data you cannot trust. It is an operational risk, not a market risk. The market can be doing exactly what your strategy expected. You still lose if you cannot act.

It includes full downtime, where the platform is unreachable. It includes partial failures, where the website works but the trading interface does not. It includes rate limiting, where the exchange rejects your requests because you sent too many. And it includes order-state uncertainty, where you sent an order and never learned whether it filled.

Outages cluster around the worst possible moments. Volume spikes during a crash. The exchange’s systems strain under the load. The traders who most need to exit are the ones who cannot. During the May 2021 crash, both Coinbase and Binance reported degraded service as volumes hit records. That pattern repeats in every sharp move.

Why Outages Hurt Algorithms More Than Manual Traders

A manual trader with a dead app opens another exchange, calls a broker, or at least knows something is wrong. An algorithm does whatever its last instruction was. If that instruction was “hold until the exit condition fires”, it holds. The exit condition may have fired three times during the outage. The bot never saw it.

The second problem is silence. An algorithm that stops receiving data often does not know it has stopped. The last price it saw becomes, in effect, the current price. It evaluates its rules against a frozen number. Nothing triggers because nothing changes. The position sits open through a move the strategy would never have tolerated.

The third problem is the restart. When the connection returns, the bot sees a price far from where it left off. Rules that assumed continuous data fire in a burst. A strategy that was designed to enter once might enter again on stale state. Our overview of algorithmic trading risks puts this category alongside market and model risk. In live trading it is often the one that bites first.

Four Ways an Exchange Fails You

Full downtime

The venue is unreachable. No orders, no data, no cancellations. This is the simplest failure and the easiest to plan for. The only question is what happens to your open position while you wait.

Rate limits and degraded mode

Exchanges cap how many requests a connection can send per minute. Binance publishes its limits in its API documentation. Exceed them and the exchange rejects requests, then bans the connection temporarily. A bot that polls aggressively during a volatile session can lock itself out at exactly the wrong time. Degraded mode is the subtler cousin. The exchange answers, but slowly. Orders queue. Fills arrive late. Your bot thinks it is flat when it is not.

Stale or gapped data

The feed keeps running but the prices are old. Or the feed drops candles and resumes with a gap. A strategy computing a 20-period average now has 19 real values and one that does not exist. Indicators built on that window produce values that look plausible and mean nothing.

Order-state uncertainty

You sent a market order. The exchange timed out before responding. Did it fill? If you send it again, you may be doubled. If you do not, you may be unprotected. This is the hardest state to handle because there is no safe default.

Where Should Your Protective Exit Live?

The single most important decision is whether your stop rests on the exchange or in your bot.

A bot-side stop is a rule your algorithm evaluates each candle. If price crosses the level, the bot sends a close order. It is flexible. It can use ATR, trailing logic, or any condition you can express. It also disappears the moment your bot loses contact with the exchange.

An exchange-side stop is an order that sits in the venue’s own system. It triggers whether your bot is alive or not. It survives your connection dropping, your server rebooting, and your rate limit tripping. It is less flexible. It is also the only protection that works during the outage itself.

The answer for most live strategies is both. Let the bot manage the intelligent exit. Place a wider hard stop on the exchange as the backstop. If the bot is working, the exchange stop never fires. If the bot is not working, the exchange stop is the only thing standing between you and an unbounded loss. Check with your venue which order types rest on their side. Not every exchange supports every conditional order, and some only hold them while a connection is open.

What Belongs in an Incident Checklist?

Write this before you need it. During an outage you will not think clearly.

How to Apply Outage Protection in Arrow Algo

Arrow Algo’s visual builder lets you express most of this checklist as blocks. That beats a document you hope to remember under pressure.

Start with the alert. Arrow Algo sends a notification by email or Telegram whenever a signal fails to execute. If the exchange rejects an order, times out, or is unreachable when your strategy fires, you hear about it straight away. That closes the silence problem described above. The bot may not know it is blind. You will. Set the Telegram option up on your phone so the alert reaches you away from the desk, where most outages find people.

Use an ATR block to set a hard stop level at entry and record it with a fixed number. That is the backstop the strategy should never widen. Run it alongside your intelligent exit, not instead of it.

Use a Time Filter block to keep the strategy flat through your exchange’s published maintenance window. The bot cannot be caught in an outage it was never trading through.

Use a Position Status block to gate every entry on “no open position”. After a reconnection the bot cannot stack a second entry on top of the first. Its state is read from the live position, not from memory.

Use a Timer block to enforce the restart cooldown. After any exit, hold off new entries for a set number of candles. That same pause protects you when the first candles after a reconnection are unreliable.

Then size the position in the backtest as if an hour-long gap is possible. If the equity curve cannot survive that, the strategy is not ready for live trading, whatever the Sharpe ratio says.

What Are the Key Takeaways?

Disclaimer: This content is for educational purposes only and does not constitute financial advice. Trading involves significant risk and you should only trade with capital you can afford to lose. Past performance is not indicative of future results. Always conduct your own research before making any trading decisions.

Ready to build your own automated trading strategies without writing a single line of code? Start for free at Arrow Algo and join thousands of traders who've made the switch to systematic trading.