A crypto trading bot should handle exchange maintenance by blocking new entries when required services are unavailable, preserving the identities of existing orders, and resuming only after market permissions, data and account state have been checked. An estimated maintenance end time is not a restart instruction. Signals collected during the interruption need an explicit expiry rule before they can become new orders.
Read the maintenance scope before changing the bot
“Exchange maintenance” can mean a matching-engine pause, a private API interruption, a deposit suspension or a brief network change. Those events affect different parts of a strategy. A deposit suspension does not establish that trading stopped; a working public ticker does not establish that orders can be managed.
Start with the official notice for the exact venue, product, environment and affected account group. Record its publication time, expected window, affected services and next update location. Convert the window into one recorded timezone, preferably UTC, so an operator and a hosted process are working from the same schedule.
Bybit's system-status API exposes maintenance scope through fields for service type, product, environment and affected UID suffixes. Its end field is an estimate before completion and becomes the actual end afterward. The documentation also says some interruptions shorter than ten seconds, or immediately recoverable WebSocket disconnections, are not announced. An empty notice list therefore cannot establish uninterrupted service. Bybit system-status documentation.
A maintenance plan must include unexpected interruption too. Define which observations cause new entries to stop even when there is no advance notice. The connection-health guide explains how to give each successful check its own scope and timestamp.
Treat reopening as a sequence of permissions
An endpoint can respond before every trading function is available. Check the venue's current trading mode and the specific instrument's eligibility, rather than inferring readiness from a website loading.
Kraken provides a useful venue-specific example:
| Kraken mode | New orders | Existing-order cancellation | Matching |
|---|---|---|---|
| Maintenance | Unavailable | Unavailable | Paused |
| Cancel only | Unavailable | Available | Paused |
| Post only | Limit orders marked post-only | Available | Paused |
| Online | All supported order types | Available under normal rules | Available |
These definitions come from Kraken's trading-mode guide. They illustrate why reachable, cancelable and executable are different conditions; similarly named modes at another venue require their own documentation. This example does not establish KLINEO connectivity to Kraken.
Kraken's developer documentation also separates the engine's status from scheduled-maintenance and emergency advisory arrays. The advisory explains an event; it does not determine the engine state. That distinction is useful when a notice has an estimated completion time but restrictions remain active. Kraken system-status endpoint.
For an existing position, check protection separately. Kraken Derivatives documents that stop-loss and take-profit orders do not activate during its post-only period, and that liquidation can occur after trading is enabled if its threshold is then met. This is a product-specific example of why an accepted stop is not a guarantee of continuous exit access. Kraken Derivatives outage options.
Prepare an exposure record before the window
Before planned downtime, decide what should happen to entries, working orders and existing exposure. Use the bot's documented controls and verify their effects at the exchange. A pause label alone cannot tell you what remains open; see DCA bot pause versus close.
Keep a protected record containing:
- The exchange, account, environment, product and symbol.
- Each outstanding intent, client order ID and exchange order ID.
- Confirmed cumulative fills, remaining quantity and last observation time.
- Protective orders and whether the exchange or application evaluates each trigger.
- The person responsible for intervention and the evidence required to resume.
Choose any cancellation or reduction policy before access becomes restricted. If the plan requires a cancellation before the window, verify the terminal result and account for fills; sending the request is insufficient. Do not cancel protective orders merely to make an order list simpler.
Keep secrets out of the maintenance record. A credential inventory label can identify the connection without copying API keys into an incident document.
Worked restart worksheet: three intents, one extended window
Consider a fictional spot bot. An announced 12:00–12:20 UTC maintenance window lasts until 12:27. Its policy blocks new entries throughout the interruption, and an unsubmitted signal expires 90 seconds after generation. These times are teaching assumptions, not recommended universal thresholds or a real exchange incident.
| Intent | Evidence at 12:27 UTC | Required disposition |
|---|---|---|
| A: submitted at 11:59; response lost | Original order ID unresolved | Reconcile that order and its fills before considering a replacement |
| B: generated at 12:18; never submitted | Expired at 12:19:30 | Discard the old entry intent |
| C: generated at 12:26; never submitted | Expires at 12:27:30 | Keep blocked while restart checks continue; reassess expiry before submission |
At 12:27, B is nine minutes old and has been expired for seven minutes thirty seconds. It does not regain validity because a connection returns. If account reconciliation ends at 12:28, C has expired too. A fresh signal may later qualify under the strategy, but that is a new decision using current conditions.
A has a different problem: it crossed the submission boundary. It cannot be discarded as an unused signal or resent because its age exceeded 90 seconds. The order-timeout reconciliation guide covers the identity and fill checks needed to resolve it.
Suppose A partially filled before maintenance. Replaying A as a fresh full-size entry while also sending B and C would combine existing exposure with three new submissions. The failure comes from treating a queue of different states as a single backlog to drain. Preserve whether each intent was never submitted, unresolved, open or terminal.
Reconcile before reopening entries
After service returns, rebuild market-data continuity and authenticated account state through the venue's supported procedures. A fresh heartbeat cannot recover missing order events. Use the WebSocket recovery guide for the feed-specific work.
Check open orders, relevant historical orders, executions, balances or positions, and protective orders. Include manual activity during the interruption. Treat discrepancies as unresolved until their cause is known; an empty open-order list cannot distinguish a filled order from a canceled one.
Before fresh entries resume on a shared account, review self-trade prevention outcomes, including how an incoming instruction could displace another strategy's intended exit.
There are endpoint-specific traps. Bybit documents that after a server release or restart, Unified-account filled, canceled and rejected records should be queried through order history. Its recent closed-order cache can be cleared during an update. A missing record in the realtime endpoint is therefore not proof that the original submission never existed. Bybit open and closed order documentation.
Keep recovery queries bounded and within the venue's API rate-limit budget. A simultaneous restart across many bots can exhaust the request capacity needed to establish account state.
Write a concrete resume decision
Record the observed trading mode, account reconciliation time, recovered data scope, disposition of each pending intent and operator approval where required. Check current balances, order rules, exposure limits and relevant price conditions before admitting a fresh entry. The resume decision should describe what was verified and what remains uncertain.
Reconcile fee currencies and available balances too: a fully filled spot purchase may have credited fewer base units than the gross fill quantity.
If an original order is unresolved, protection cannot be confirmed, or required account access is still unavailable, keep new entries blocked and escalate using the exchange's official channels and supported controls. A return of network access does not settle those questions.
For a KLINEO workflow, the activation and recovery guide is a starting point for supported operations. The worksheet here is an educational operating policy; it does not claim that KLINEO automatically imports exchange maintenance calendars or applies this restart sequence.
Editorial method: Prepared with AI assistance on 23 October 2026 using the official documentation linked above and KLINEO's product brief. The intent worksheet and expiry calculations are original hypothetical examples. No live outage test, customer incident or uptime measurement is claimed.