Exchange outages and degraded mode
Figures on this page are as of 2026-09. Fees, limits and margin tiers change — check the venue's own docs before acting on a number.
A clean outage is the easy case — nothing works and you know it. The dangerous case is partial degradation: reads work and writes do not, or orders are accepted and confirmations are not returned, and your automation continues as though everything is fine.
Outages cluster with volatility, which is when your positions most need attention.
The failure modes, in order of nastiness
Clean outage. Everything returns errors. Easy to detect, and your code should stop.
Read-only degradation. Market data flows, orders fail. Your strategy sees signals it cannot act on. If entries fail and exits fail too, you are holding positions you cannot manage — which is the scenario to plan for.
Write-accepted, confirmation-lost. The worst. Orders may be executing while you cannot see results. Every response is ambiguous, and every retry is a potential duplicate.
Stale data. The stream is connected and the data is old. Nothing errors — see WebSocket reconnection patterns. Decisions are made on prices that no longer exist.
Scheduled maintenance. Announced, and still breaks anything that assumed
continuous availability. CCXT models it as OnMaintenance under
ExchangeNotAvailable.
Partial symbol availability. Some markets halted, others trading. Your strategy discovers it one symbol at a time.
Detecting degradation
Errors alone are insufficient, because the dangerous modes do not throw.
Data freshness per stream. Time since the last message. This is the only detector for stale data, and it costs nothing.
Error rate over a window. A single failure is noise; a rate change is a signal. Track the proportion, not the count.
Latency distribution. Rising latency usually precedes an outage and is visible before errors are.
Write-path health separately from reads. They fail independently, so monitoring “the API is up” tells you about whichever you happened to test.
Reconciliation mismatch. If your position view diverges from the exchange’s, something is wrong regardless of whether anything errored.
What degraded mode should do
The hard part is deciding in advance, because the moment it triggers is not when you want to be designing behaviour.
Stop opening. New positions require working infrastructure. This should be the first thing to go and the least controversial.
Keep trying to close. Exits are the priority, and reducing exposure is the one action worth retrying aggressively. This mirrors the rule that a daily loss limit must exempt closing orders — a control that blocks exits is worse than no control.
Never retry an ambiguous write blind. Reconcile first: open orders, recent fills, position. Three requests, and it replaces a guess with a fact.
Fail closed on unknown state. If you cannot establish what you hold, stop acting. A halted strategy is recoverable; one trading on a wrong position is not.
Alert loudly. Degradation is exactly the case where a human should be looking.
What not to do
Do not hammer. A struggling venue plus aggressive retries earns a rate limit
you cannot afford — and on Binance, severe violations escalate from 429 to an
HTTP 418 IP ban that outlasts the burst. See
Binance API rate limits.
Do not switch venues mid-position as an outage response. Hedging on a second exchange creates two positions and two sets of problems, and unwinding is now conditional on both venues working.
Do not assume a cancel succeeded because it returned an error. Cancels are writes and are equally ambiguous.
Do not resume automatically after recovery without reconciling first. The gap between “the API is back” and “I know what I hold” is where positions get doubled.
The uncomfortable planning question
If the venue goes down while you are in a leveraged position, what happens?
Your stop is a resting order on that venue. If matching is halted it does not execute; if it is executing while you cannot see it, you do not know your state. Meanwhile, funding and margin continue to apply — and liquidation is performed by the venue, which may function when your API access does not.
There is no clever technical answer. The practical ones are:
- Size so an unmanaged position is survivable. This is the real mitigation, and it is a sizing decision made in advance.
- Keep leverage low enough that a gap does not reach liquidation — see the leverage and stop-loss table.
- Know the venue’s mobile or web fallback, and have it working before you need it.
- Do not concentrate everything on one venue if the position sizes make an outage account-threatening.
Recovery
Reconcile before anything else. Positions, open orders, recent fills. Do not skip this because the API is responding again.
Check for orders you did not intend. Ambiguous writes during the outage may have executed.
Check for missing protective orders. A stop that was cancelled or never placed leaves an unprotected position — the check from monitoring a trading integration.
Resume deliberately. Automatic resumption on the first successful request is how a partially-recovered venue produces a second incident.
FAQ
What should my trading bot do during an exchange outage?
Stop opening new positions immediately, keep attempting to close existing ones, never retry an ambiguous write without reconciling first, and alert a human. Then reconcile fully before resuming — the gap between the API responding again and you knowing what you hold is where duplicate positions come from.
How do I detect a partial outage?
Not from errors alone, since the dangerous modes do not throw. Track data freshness per stream, error rate over a window rather than single failures, latency distribution, and the health of reads and writes separately — they fail independently. A position mismatch against the exchange is also a signal regardless of whether anything errored.
What happens to my stop-loss if the exchange goes down?
It is a resting order on that venue, so it executes only if matching is running. If the venue is halted it does not fire, and if it is running while your API access is not, you cannot see whether it did. Meanwhile funding and liquidation continue to apply. The mitigation is sizing, not technology.
Should I hedge on another exchange during an outage?
Generally no. It creates two positions across two venues, and unwinding now depends on both working. The exposure you were worried about has been replaced by a more complicated one that is harder to exit.