Running a Trading Bot 24/7 on Windows: Restarts, State, and Health OnTech Insight

TECH INSIGHT / EXPLAINED

A bot that stays running and a bot that safely resumes trading are different operational states. On Windows, plan for reboot, sleep, failed upgrades and uncertain orders before relying on automatic restarts. Running all day does not mean trading outside the market’s supported session.

Three adult colleagues explain windows operations — AI-generated teaching illustration, not an actual operating screen or performance record.

Give the scheduler a precise process contract

Use an absolute executable path, a deliberate working directory and the intended service user. That user must be able to read the required configuration and credential store. Avoid overlapping task instances. Test after reboot without an interactive login if that is the required operating mode; an interactive tray app is not a Windows service.

These PowerShell settings create an object for a task definition; they do not register or launch a task. IgnoreNew prevents the scheduler from starting another instance of this same task, but does not prevent someone from launching a second executable manually. The zero execution-time limit removes the scheduler’s runtime limit. The restart settings bound scheduler retries; they are not a complete crash-loop policy.

# Creates a settings object only; it does not register a task.
$botSettings = New-ScheduledTaskSettingsSet `
    -MultipleInstances IgnoreNew `
    -RestartCount 3 `
    -RestartInterval (New-TimeSpan -Minutes 1) `
    -ExecutionTimeLimit ([TimeSpan]::Zero)

Event	Intended policy
Operator stop / successful exit	Exit 0 and remain stopped until explicitly started.
Transient process failure	Retry with delay and an attempt budget; reconcile before enabling entries.
Invalid configuration / unavailable credentials	Keep entries disabled and expose a clear failure; fix the cause before recovery.
Repeated failures across launches	Persist a circuit-breaker state and alert; avoid an endless wrapper loop.

The scheduler cannot infer all of these causes from one generic nonzero exit code. Implement application readiness and an explicit supervisor policy where needed. A batch file that loops forever after any exit also restarts deliberate shutdowns and hides persistent faults.

Persist evidence, then reconcile on startup

Keep a versioned state record containing account identity, session key, order intents and last reconciliation time, without credentials. Writing directly over the only JSON file risks truncation. A transactional local database is one option; a file design needs a tested replacement protocol, validation and a recoverable prior version. On startup load and validate state, query broker orders and balances, resolve uncertain requests, restore subscriptions, then enable entries. A saved “flat” flag cannot override a live filled order.

Distinguish liveness from readiness

A local liveness endpoint can report that the process responds. Readiness should also depend on accepted configuration, credentials, fresh required market data and completed reconciliation. Publish sanitized status, bind locally by default and do not expose account details or control actions publicly. Minimized or hidden console windows are not tray functionality. Test power and sleep settings, maintenance restarts, time synchronization and a stopped-bot alert using the actual Windows account and machine.

Documentation and next steps

Content and examples reviewed: 2026-09-29

Running a Trading Bot 24/7 on Windows: Restarts, State, and Health