What Happens to Automated Orders During Exchange Maintenance Windows

If you automate crypto trades, there is one interruption you cannot control and cannot fully avoid: exchange maintenance windows for automated orders. Every major exchange takes its systems offline from time to time — sometimes on a published schedule, sometimes without warning. When that happens, the order you expected to fire instantly may be delayed, rejected, or silently dropped. Understanding exactly what happens during these windows is the difference between a resilient automation setup and one that quietly fails at the worst possible moment.

This guide explains what a maintenance window is, what actually happens to your orders when an exchange goes down, how scheduled and unplanned downtime differ, and how to build automation that handles both without leaving you guessing.

What an exchange maintenance window actually is

A maintenance window is a planned or unplanned period when an exchange takes part of its infrastructure offline. During this time the exchange may pause trading on some or all markets, disable order placement through its API, or restrict deposits and withdrawals while keeping the rest of the platform live.

Maintenance falls into two broad categories. Scheduled maintenance is announced in advance — the exchange posts a start time, an expected duration, and which services are affected. Unplanned downtime is the opposite: an outage triggered by a bug, a traffic spike during high volatility, or a hardware failure. Both interrupt automated order flow, but you can prepare for one and only react to the other.

The important detail for automation is that maintenance is rarely all-or-nothing. An exchange might keep its website reachable while its trading API returns errors, or allow spot trading while futures are frozen. Your automation talks to the API, so what matters is the state of that specific interface, not whether the exchange homepage loads.

What happens to your orders when the exchange goes down

When an exchange enters maintenance, an order your strategy submits can meet one of several fates. It may be rejected outright with an error, held in a queue and processed late, or accepted but never acknowledged because the connection dropped mid-request. Each outcome demands different handling.

A clean rejection is the easiest case. The exchange returns an error code — often signalling that the market is in maintenance or that the endpoint is temporarily unavailable — and your system knows the order did not go through. The danger case is ambiguity: your request times out with no response. You do not know whether the exchange received the order and will act on it once systems return, or whether it never arrived at all. Resending blindly risks placing the same order twice; doing nothing risks missing it entirely.

This uncertainty is why naive automation is fragile. A script that fires an order and assumes success will drift out of sync with reality the moment an exchange pauses. Good execution infrastructure treats every unacknowledged order as unknown until confirmed, and reconciles state once the exchange is back rather than trusting that the request landed.

Scheduled versus unplanned downtime

Scheduled maintenance is the friendlier of the two because you can see it coming. Exchanges publish maintenance notices through status pages, API announcements, and email. If your automation is aware of these windows, it can pause new order submission, hold signals in a buffer, or flag them for review instead of throwing requests at a dead endpoint.

Unplanned downtime gives you no warning, so the only defense is how your system behaves under failure. The questions that matter are whether your automation detects an error quickly, whether it retries safely, and whether it avoids duplicating an order it is unsure about. A setup that answers those three questions well will survive an unexpected outage; one that assumes the exchange is always reachable will not. If you want to go deeper on the failure side, our guide on retries and timeouts for automated orders covers the mechanics in detail.

How automated order flow breaks during maintenance

Automation adds speed, but it also removes the human who would notice something is wrong. A manual trader watching the screen sees the maintenance banner and simply waits. An automated pipeline keeps firing signals into a wall unless it is told to stop.

The typical break points are the same across setups. A signal fires from your strategy or alert. The order request reaches the exchange API, which is offline or degraded. Without retry logic, the request fails and the signal is lost. Without idempotency, a retry can place a duplicate once the exchange recovers. And without state reconciliation, your records show an order that the exchange never filled — or miss one it did. Handling rejections cleanly is its own discipline, which we cover in managing failed and rejected orders.

Latency makes this worse near the edges of a window. As an exchange winds down or spins back up, response times climb and partial failures spike. An order submitted in those minutes is the most likely to end up in an unknown state, which is why latency in automated trading matters most precisely when the exchange is least stable.

Best practices for handling maintenance windows

You cannot stop an exchange from going offline, but you can make sure your automation degrades gracefully instead of failing silently. The core habits are straightforward:

• Watch the exchange status page or API announcements so scheduled windows are known before they start.
• Pause or buffer new order submissions during a known maintenance window rather than firing into a dead endpoint.
• Use idempotency keys so a retried order can never become a duplicate order.
• Treat any timed-out or unacknowledged request as unknown, and confirm real state through the exchange rather than assuming.
• Reconcile open orders and positions the moment the API returns, before resuming normal flow.
• Log every rejection and timeout with enough context to see what happened after the fact.

None of these require predicting the market. They are process controls that keep your execution layer honest when the exchange it depends on is temporarily unreliable.

How a relay layer handles maintenance windows

Most of the work above is infrastructure, not strategy — and infrastructure is exactly what a relay layer exists to own. A non-custodial relay sits between your signal source and the exchange, so retry logic, idempotency, and state reconciliation live in one place instead of being reinvented in every script. When an exchange enters maintenance, the relay detects the failing endpoint, avoids blind resubmission, and reconciles once the API is healthy again.

Because the relay uses trade-only API keys with no withdrawal access, your funds never leave your own exchange, even during an outage. The relay can only place orders on your behalf — it can never move your balance. That separation matters most in the messy minutes around a maintenance window, when a less careful system might duplicate or lose an order. SignalToExchange is built for exactly this: reliable order submission that treats every exchange interruption as a state to reconcile, not a request to fire and forget.

Frequently Asked Questions

Will my order still execute after maintenance ends?

It depends on how it was submitted. An order rejected during maintenance will not execute unless your system resends it. An order the exchange accepted before pausing may still be live when trading resumes. This is why confirming real state after a window is essential — you cannot assume either outcome.

Can I schedule my automation around maintenance windows?

For scheduled maintenance, yes. If you know the start time and duration, your automation can pause new submissions and buffer signals until the exchange is back. Unplanned outages cannot be scheduled around, so your system must also handle failures reactively.

How do I avoid placing duplicate orders after an outage?

Use idempotency keys. Each order carries a stable, unique identifier so that if the same request is retried, the exchange or relay recognises it as a repeat and does not create a second order. Without this, a retry after an ambiguous timeout is the most common cause of duplicates.

Does using a relay expose my funds during an outage?

No. A non-custodial relay uses trade-only keys that can place orders but cannot withdraw. Your balance stays on your own exchange at all times, including during maintenance. The relay only ever has permission to trade.

Which exchanges have maintenance windows?

All of them at some point. Every major venue — Binance, Bybit, Kraken, OKX, Coinbase, KuCoin, Bitget — performs scheduled maintenance and occasionally experiences unplanned downtime. The specifics vary, so check each exchange's status page for its own notices.

Maintenance windows are one of the few certainties in automated trading, so the smart move is to plan for them rather than hope they never land on a live signal. Build in retries, idempotency, and reconciliation, or let infrastructure handle it for you. Request access or start your free trial to see how SignalToExchange routes signals securely and keeps execution resilient when exchanges go offline.

Automated trading involves risk. SignalToExchange is execution infrastructure and does not provide financial advice, trading signals, or guarantees of any kind.