Skip to content
Aurono Support auronolabs.com →

What Happens During Exchange Downtime

Exchanges are external systems.
Occasionally, they may experience downtime, degraded performance, or partial outages.

Aurono is designed to handle these situations safely and predictably.

This page explains what happens when an exchange is unavailable and what it means for your strategies.

What Counts as Exchange Downtime

Section titled “What Counts as Exchange Downtime”

Exchange downtime can include:

  • API endpoints being temporarily unavailable
  • Slow or delayed API responses
  • Order placement failures
  • Delayed or unavailable order status updates
  • Market data temporarily not updating

These conditions are controlled entirely by the exchange.

Aurono’s Core Principle During Downtime

Section titled “Aurono’s Core Principle During Downtime”

Aurono follows a simple rule:

If the exchange cannot confirm an action, Aurono does nothing.

Aurono never guesses, assumes, or retries aggressively.

Strategy Evaluation During Downtime

Section titled “Strategy Evaluation During Downtime”

When a strategy is scheduled to evaluate:

  1. Aurono attempts to load the required market data
  2. If market data cannot be retrieved:
    • The evaluation is skipped
    • No trade is attempted
    • The event is logged

Aurono does not:

  • Use stale data
  • Re-evaluate past candles
  • Backfill missed executions

Each evaluation is independent.

Order Placement During Downtime

Section titled “Order Placement During Downtime”

If a trade is triggered but the exchange is unavailable:

  • The order is not placed
  • No funds are reserved
  • No partial execution occurs

Aurono does not:

  • Queue orders for later
  • Retry endlessly
  • Place orders once the exchange recovers automatically

The strategy simply waits for the next evaluation cycle.

Order Status Checks During Downtime

Section titled “Order Status Checks During Downtime”

:::warning Unresolved orders during downtime If an order was successfully submitted but the exchange became unavailable before Aurono could retrieve its final status, that order may remain unresolved in Aurono.

In this situation:

  • The order may still be open, partially filled, or fully filled on the exchange
  • Aurono does not automatically retry status checks
  • Balances and allocations are not updated until execution details are explicitly confirmed

Aurono intentionally avoids guessing or reconciling these orders automatically.
If this occurs, users should check the order directly on the exchange and, if needed, resolve it manually.

This behavior prioritizes safety and correctness over automation. :::

If an order was already submitted and the exchange becomes unavailable:

  • Aurono attempts a single status check shortly after submission
  • If the exchange does not respond, no assumptions are made
  • The order remains fully managed by the exchange

Aurono does not:

  • Continuously retry status checks
  • Cancel or replace the order automatically
  • Infer execution results without confirmation

If the exchange is unreachable during this status check, the order remains unresolved in Aurono until manual inspection.

No duplicate orders are created.

Capital and Balance Safety

Section titled “Capital and Balance Safety”

During downtime:

  • Allocated capital is not modified unless an order submission was confirmed
  • No new exposure is created
  • No forced actions occur

Aurono never:

  • Assumes an order was filled
  • Assumes an order failed
  • Adjusts balances without explicit exchange confirmation

All state changes require direct confirmation from the exchange.

Logging and Visibility

Section titled “Logging and Visibility”

All downtime-related events are logged, including:

  • API errors
  • Timeouts
  • Skipped evaluations
  • Failed order submissions
  • Unavailable order status responses

This ensures:

  • Transparency
  • Clear diagnostics
  • No “silent” behavior

Downtime is visible, not hidden.

What Aurono Does Not Do

Section titled “What Aurono Does Not Do”

Aurono does not:

  • Retry aggressively
  • Spam API requests
  • Queue failed trades
  • Automatically reconcile unresolved orders
  • Switch execution modes
  • Fall back to market orders
  • Change strategy parameters
  • Catch up on missed trades

This is intentional.

What Happens After Recovery

Section titled “What Happens After Recovery”

Once the exchange is available again:

  • Strategies resume normal evaluation on the next scheduled cycle
  • Only future candles are considered
  • No retroactive trades occur

Aurono does not try to “make up” for missed opportunities or unresolved past orders automatically.

Why This Design Is Intentional

Section titled “Why This Design Is Intentional”

This behavior ensures:

  • No unintended trades
  • No surprise executions
  • No duplicated orders
  • No hidden retries
  • A deterministic and auditable trading engine

Aurono prioritizes safety, correctness, and predictability over activity.

What You May Notice as a User

Section titled “What You May Notice as a User”

During exchange downtime, you may see:

  • No new trades
  • Log entries indicating API or connectivity errors
  • Temporary inactivity
  • Orders that remain open on the exchange until reviewed

This is expected behavior.

Aurono being inactive during downtime is a sign that it is working correctly.

Key Takeaway

Section titled “Key Takeaway”

During exchange downtime:

  • Aurono fails safely
  • No assumptions are made
  • No trades are forced
  • No duplicate orders occur
  • State changes only happen with explicit confirmation

When the exchange recovers, Aurono continues normally from the next evaluation cycle.

Section titled “Related Pages”
  • Logging & Diagnostics
  • API Rate Limits & Request Frequency
  • Trading Engine — How Aurono Executes Trades
  • Troubleshooting