Bot Restarts: Why a Bot Forgets Its Position When Switched Off and On

An automated trading bot will eventually stop: for a code change, a power outage, or a program crash. The problem is not the stop but the moment it starts again. The position is still in the account, while the bot begins with no memory of it.

Where Does a Bot Keep Its Memory?

While running, the bot knows whether it is long or short, its entry price, where the stop is, and how many times it has averaged down. Most of that information lives in program memory, which disappears when the program exits.

This mismatch is the starting point of every restart incident. From the bot's perspective, it has just been born, so “I hold nothing” is the default. The account, however, remained active throughout the shutdown. Handling this difference shares its roots with position reconciliation, but a restart is a moment when that mismatch definitely occurs.

What an Amnesiac Bot Does on Its First Cycle

Most bots inspect market prices and calculate signals as soon as they start. If the bot believes it has no position, it simply enters a new one when a signal qualifies.

The result resembles a duplicate order. The cause differs: there, a response was lost; here, memory was lost, so the same entry happens twice. The last line is particularly bad. Because the bot manages only the 0.1 it submitted, the remaining 0.1 stays in the account even after the stop triggers. A position with nobody managing its stop has been created.

The opposite direction is also possible. If a short signal appears after restart, the bot enters a short because it believes it is flat. The account either holds the existing 0.1 long and a new 0.1 short simultaneously in hedge mode, or the long is offset and disappears in one-way mode. Either way, the bot's records and the account tell completely different stories.

Do Not Place Orders on the First Cycle

The first step is simple. Instead of making a decision immediately after startup, check the current state first.

The final line is the most common practical mistake. If a failed query produces an empty value and that value is read as no position, the bot confidently enters again. Unknown and absent are different. In an unknown state, the correct response is to place no orders. This is the same principle discussed in WebSocket disconnections: silence must not be interpreted as information.

What Needs to Be Saved?

Some information cannot be recovered from an exchange query. The exchange provides quantity and average entry price, but only the bot knows why it opened the position.

State must therefore be written to a file whenever the trade changes, instead of remaining only in memory. Record changes when entering, adding, moving a stop, or closing: at the moment a value changes. Saving in batches every few minutes means changes since the last save disappear on restart.

A Gap in Save Timing Leaves an Incomplete Record

What happens if the program crashes after submitting an order but before writing the record? The remaining evidence depends on the order of events.

No sequence can eliminate the possibility of crashing between the steps. Instead of trying to make the sequence perfect, impose the rule that startup must always reconcile. Starting from the assumption that records may be wrong makes an incomplete record something to correct, rather than an incident.

The program can also crash while writing a file, leaving it corrupt and unreadable. Writing the entire contents to a temporary file and then renaming it leaves either the old contents or the new contents, never an intermediate state.

Restarts Arrive Without Warning

Not every restart is planned. Unexpected ones are often more common.

Cleanup code that handles shutdown signals is useful, but cannot be your only protection. When power disappears, no cleanup code runs. Save whenever values change, rather than only when shutting down.

Automatically starting the bot after a reboot belongs to the same discussion. However, state recovery must be in place before automatic restart is enabled. Without recovery, a single power outage can make the bot submit a duplicate entry by itself. Temporarily blocked queries during exchange scheduled maintenance should be handled the same way: if the state is unknown, stop.

What to Check Before Restarting

When restarting manually, you can choose the timing. That alone eliminates many incidents.

Here is what that last combination means. If a stop loss exists only as bot logic that watches prices and closes at market, rather than as an actual exchange order, the position has no stop while the bot is off. Whether restart takes five minutes or an hour, it remains unprotected throughout. During development with frequent restarts, placing the stop as an exchange order is safer.

Do not skip checking that only one process is running. If a new process starts before the old one has stopped, two bots place orders in the same account. Even excellent state recovery cannot solve this: each bot recovers independently and submits its own orders.

How to Verify Recovery

Restart recovery is invisible during normal operation and reveals itself when an incident occurs. It therefore needs deliberate testing.

The last two lines are essential. If a missing or corrupt state file causes the bot to quietly start from scratch, that is the most expensive failure mode. When the file is wrong, the appropriate response is to stop and alert. General integration and authentication are covered in the exchange API integration guide.

Summary

In one sentence: assume the bot can crash at any time, and make it query the account again every time it starts. With this structure, restarting becomes a routine operation rather than an incident.

Caution

The quantities, prices, margins, leverage, and P&L figures here are hypothetical examples explaining the structure, not measurements from a specific exchange. Position and order queries, one-way and hedge-mode behavior, persistence of conditional orders after restart, and query rate limits differ by exchange. Check your exchange's documentation and test with a small amount. Leveraged trading can lose all principal, and you are responsible for investment decisions and their results.