Crypto markets never close. Your bot has to survive nights, weekends, power cuts, kernel updates, memory leaks, and the exchange dropping your WebSocket at the worst possible moment. Uptime isn't one setting — it's a stack of small, boring defenses that each catch a different failure. Here's what actually keeps a bot alive.
What actually takes a trading bot down?
Very rarely a dramatic crash. Usually something dull. In rough order of how often I've seen them:
- The process dies — an unhandled exception, an out-of-memory kill, a null response the code didn't expect.
- The connection drops — the exchange resets your WebSocket every 24 hours anyway, and your reconnect logic has a bug.
- The machine reboots — a VPS host migration or an OS update at 4am, and nothing restarts the bot.
- The network flaps — DNS hiccup, IP rate-limit, or a regional outage between you and the exchange.
- The exchange is down — maintenance windows and API degradation you can't control.
Each of these needs a different fix. A restart policy handles the first three. Reconnection logic handles the fourth. Only reconciliation and a dead-man's-switch handle the fifth safely.
Where should the bot live?
Not on your laptop. A machine that sleeps, updates, or loses Wi-Fi will kill your bot the night it matters. A small cloud VPS — even a $5–10/month instance — gives you a static IP, a stable network, and 99.9%+ uptime you don't have to babysit. Put it in a region close to your exchange's servers to shave latency, which matters more for market making than for slower DCA or grid strategies.
Home servers work if you have a UPS, a second internet line, and the patience to maintain them. Most people don't. The full trade-off — cost, latency, control, and reliability — is worth thinking through in VPS vs home server for trading bots. For most retail bots, a VPS is the boring correct answer.
How do you keep a trading bot running when the process crashes?
Wrap it in a process manager that restarts it automatically. Don't run python bot.py in a terminal and walk away — the moment that shell closes or the script throws, you're offline. Three common options:
- systemd (Linux native): a unit file with
Restart=alwaysandRestartSec=5relaunches the bot on any exit and starts it on boot. Zero extra dependencies. My default. - pm2 (Node/Python): easy log management and
pm2 startupfor boot persistence. It backs off between rapid restarts so a crash loop doesn't hammer the CPU. - Docker with
restart: unless-stopped: the container comes back after a crash or host reboot, and aHEALTHCHECKcan force a restart when the app is alive but wedged.
Set a restart cap or backoff. A bot that crashes on a specific bad tick will restart, hit the same tick, and crash again forever — burning API rate limits and doing nothing. Backoff plus an alert (below) turns an infinite loop into a page you can act on.
How do you make a bot safe to restart?
Auto-restart is dangerous if the bot forgets what it was doing. A naive restart can double-submit an order it already placed, or re-open a position it just closed. Three habits prevent that:
- Persist state to disk or a small database — open orders, current position, last processed candle — not just in memory.
- Reconcile on startup: before trading, query the exchange for your actual open orders and positions and sync the bot's view to reality. The exchange is the source of truth, not your saved state.
- Use client order IDs (idempotency keys). If you retry a submit after a crash and reuse the same client ID, the exchange rejects the duplicate instead of filling twice.
This is the difference between a restart that quietly resumes and one that opens a second unwanted position at 3am. The mechanics of how these calls actually work live in how bots connect to exchanges via API.
What monitoring and alerting do you need?
A restart policy fixes crashes you can see. The nastier failures are the silent ones — the process is "running" but stuck in a reconnect loop, or the exchange returns 200s but your orders aren't filling. You need to watch from the outside.
The simplest, most reliable pattern is a heartbeat with a dead-man's-switch: your bot pings a service like Healthchecks.io every minute; if the ping stops, the service alerts you. It flips the logic around — instead of trying to detect every failure mode, you detect the absence of "I'm fine." That catches crashes, hangs, network loss, and a dead VPS with one check.
Good trading bot monitoring layers a few signals:
- Liveness — is the process pinging its heartbeat?
- Trading health — time since last successful order or fill; alert if it's unexpectedly long.
- Balance and position drift — alert on a sudden equity drop or a position larger than the bot should ever hold.
- Error rate — a spike in API errors or rejects usually precedes a real outage.
Route alerts somewhere you'll actually see at night — Telegram, a phone push, or SMS for the critical ones. An email you read at 9am is not monitoring.
Do you need failover and redundancy?
Usually no — and naive failover is worse than none. The obvious idea is to run two copies of the bot so one takes over if the other dies. The trap: for a few seconds both are alive, both see the same signal, and both fire the same order. Now you're 2x leveraged by accident.
If you genuinely need high availability, use one of these instead of blind duplication:
- Leader election / a shared lock so exactly one instance is allowed to trade at a time; the standby only takes over after the lock expires.
- An exchange-side dead-man's-switch (many venues, including Binance and dYdX, support an "auto-cancel all orders after N seconds" timer). Your bot refreshes the timer while healthy; if it goes dark, the exchange cancels your resting orders automatically. This is the single highest-leverage safety net for uptime — it protects you even when every other layer fails.
For most retail setups, a fast auto-restart plus a dead-man's-switch beats a full hot-standby you'll misconfigure. The stakes are higher on perps: a down bot still holds an open position paying or receiving funding every 1–8 hours and can be liquidated while you're offline. Sizing that risk is its own topic — see how deep a drawdown is too deep.
How do you handle exchange-side downtime and reconnects?
You can't keep the exchange up, but you can fail gracefully. Build reconnection with exponential backoff and jitter — retry after 1s, 2s, 4s, 8s, capped, with a little randomness so you don't hammer the API in lockstep with every other bot the moment it recovers. On reconnect, don't assume nothing changed: re-run your reconciliation step and refresh the order book snapshot before acting.
Decide in advance what the bot does when the market data goes stale: for most strategies, the safe default is to stop opening new positions and, if you can, cancel resting orders rather than trade on data you can't trust. Where your bot lives changes this picture too — on-chain bots face RPC outages and mempool congestion instead of REST maintenance windows, a contrast covered in on-chain vs CEX trading bots.
One more boring but essential defense: keep your API keys and secrets off the same disk your logs and backups sync to. Uptime and security fail together more often than you'd think — the API key security checklist covers the leaks that turn a stable bot into a drained account.
Frequently asked questions
Do I need a VPS to run a trading bot 24/7?
Practically, yes. A laptop sleeps, updates, and loses Wi-Fi, and any of those kills the bot overnight. A small VPS gives you a static IP, stable networking, and reliable power for a few dollars a month. A home server can work only if you add a UPS and redundant internet, which most people won't maintain properly.
What's the best process manager for a trading bot?
On Linux, systemd is the simplest robust choice — one unit file with Restart=always handles crashes and reboots with no extra software. pm2 is friendlier for Node and gives clean logs. Docker with restart: unless-stopped adds isolation and a healthcheck. All three work; pick the one you'll configure correctly and actually monitor.
How do I stop my bot from placing duplicate orders after a restart?
Reconcile before you trade. On startup, query the exchange for your real open orders and positions and sync the bot to that, since the exchange is the source of truth. Use client order IDs so any retried submit is rejected as a duplicate rather than filled twice, and persist state to disk instead of only in memory.
What happens to my open position if the bot goes down?
It stays open. Spot positions just sit there, but perpetual futures keep accruing funding every 1 to 8 hours and remain exposed to liquidation while you're offline. That's why an exchange-side dead-man's-switch matters: it auto-cancels resting orders when the bot stops checking in, limiting damage even if every other layer fails.
How do I get alerted when my bot fails at night?
Use a heartbeat with a dead-man's-switch. Have the bot ping a service like Healthchecks.io every minute; if the pings stop, it alerts you. This detects crashes, hangs, network loss, and a dead server with one check. Route critical alerts to Telegram or a phone push, not email you'll read the next morning.
Sources
- systemd.service manual — Restart= and RestartSec= directives (freedesktop.org)
- PM2 documentation — startup script and process persistence
- Docker documentation — restart policies and starting containers automatically
- Healthchecks.io documentation — dead-man's-switch cron and heartbeat monitoring
- Hyperliquid documentation — API, WebSocket, and funding mechanics
- Investopedia — The Pros and Cons of Automated Trading Systems