What actually happens in the ten seconds after your trading bot's process dies?
Not "does it crash." Everything crashes eventually, a bad exchange response, an out-of-memory moment on a Raspberry Pi, a power blip. The question that decides whether that moment costs you money is what happens next, automatically, before you ever notice. "I want something that just runs" is the whole ask behind crypto trading bot uptime, and it's a reasonable one. It's also a different question than "why would I trust a server I don't control with trade permissions on $X of crypto," because a SaaS vendor's uptime and your uptime are not the same thing even when the marketing page implies they are.
TradeArmor is where I put all of this to work: self-hosted, my keys never leave my hardware, three years of live BTC/USDC signal history behind it, 15 indicators running in real time, a plain-English AI strategy builder, and DCA, grid, futures, copy trading, backtesting, paper trading, and tax exports built into the same platform. None of that runs if the process isn't up. This is the part of self-hosting nobody puts on a landing page: reliability becomes your job, and it's worth knowing exactly what that job involves before you assume it away.
What Crypto Trading Bot Uptime Actually Means
A machine that's powered on with a crashed Python process is not up. The distinction matters because "is the light green" is the wrong question. The right one is narrower: can the bot place an order right now, this second, if a signal fires. SaaS bots love printing "99.9% uptime" on a pricing page. That number describes their server's availability, not whether your specific account's order made it through the queue the one time a market actually moved. It's a real statistic about the wrong thing.
Self-hosting flips who owns that number. Your uptime is a property of your machine, your restart policy, and your network, not a stat a vendor reports about infrastructure you'll never see. That's more responsibility. It's also the only version of the number that's actually about your trades. See the full feature set this runs on before you decide how much of that responsibility you're taking on.
When the Process Crashes
A crash is not a failure of the strategy. It's usually something mundane: a dependency hiccup, a momentary loss of network, memory pressure on constrained hardware. What determines the cost is how fast the process comes back and whether it comes back in the same state, DCA legs intact, position tracking unbroken, not the crash itself.
On Windows, the service installer and Task Scheduler integration exist for exactly this: the bot runs as a Windows service that survives reboots and logouts, not a terminal window someone has to remember to reopen. On Linux, the equivalent primitive is a systemd unit with Restart=on-failure or Restart=always, the operating system's own answer to "bring this back the moment it dies." Neither is exotic. Both turn a crash from an incident into a non-event, provided you actually set them up instead of running the bot in a terminal you close by accident.
Docker's Restart Policies, and the Gap They Don't Cover
Running TradeArmor in Docker adds a restart policy as a one-line config, but the four options behave differently enough that picking the wrong one quietly defeats the point. Docker's own documentation lays out the mechanics: always restarts a container after a crash and after the Docker daemon itself restarts, which happens on a host reboot, even for a container you'd stopped manually before that reboot. unless-stopped does the same, except it respects a deliberate stop and won't bring the container back until you restart it yourself. Leave the policy unset entirely and a crashed container just sits there, dead, until a human notices and types the command.
One detail catches people who set this up once and never think about it again: a container generally needs to stay running for roughly ten seconds before the restart policy engages. A bot that crashes immediately on a bad config file won't loop-restart its way to stability, it'll just sit down. The fix isn't a restart policy, it's fixing the config, and no amount of always substitutes for that.
Losing the Machine Entirely
A restart policy assumes the machine underneath it is still there. Power loss, a router reboot mid-signal, an ISP outage, these take the whole host down, and no in-process policy survives that. What matters afterward is whether the machine is configured to boot automatically when power returns and whether the bot's service or container is set to launch on startup rather than waiting for someone to log back in and start it by hand.
This is the specific tradeoff a VPS removes. A data-center box has redundant power and a network path that isn't sharing a router with the rest of your house. It doesn't remove every failure mode, the process can still crash, an exchange's API can still have a bad afternoon, but it removes an entire category that has nothing to do with the bot itself and everything to do with where it happens to be plugged in.
How You Actually Find Out Something Broke
None of the above matters if you don't know it happened. A crash you find out about from your own P&L three days later isn't monitoring. It's archaeology. The error and crash trigger under Alerts and Notifications, routed to Discord, Telegram, or email, exists specifically for the failure that doesn't fix itself: a config problem, an exchange rejecting every order, a restart loop that never stabilizes. Pair it with the daily summary trigger for the quieter case, nothing threw a clean error, the bot's just been idle longer than it should be. One catches the loud failure. The other catches the silent one.
Running more than one instance adds its own visibility layer. The proxy fans a signal out to every registered bot and tracks delivery per instance, connected or disconnected, so a machine that quietly dropped off shows up as a status change in the admin view instead of a mystery you piece together later from missing trades.
Auto-Updates Without an Uptime Hit
"Set and forget" as a slogan quietly leaves out "forgot to check if it's still running," and updates are the one place downtime is self-inflicted if you're not careful. TradeArmor's one-click update replaces files and restarts the process, a gap measured in seconds. Windows can't overwrite files a running process has open, so the update stages into a temp location and a deferred batch script swaps the files after the bot exits, then restarts it, working around a limitation of the platform rather than pretending it doesn't exist. Docker's version is simpler: since the code is volume-mounted, a container restart is the entire update. Either way, the release notes travel with the update itself, so you know what changed before you decide when to apply it.
What Uptime Can't Fix
A bot that never goes down still trades into a market that does whatever it wants. Signals are algorithmic outputs, not personalized investment advice, and past performance is not indicative of future results. Reliability engineering closes the gap between "the strategy would have worked" and "the strategy actually ran." It does not close the gap between a good strategy and a bad one, and it does not remove market risk. The honest version of "uptime" is narrower than it sounds: the process kept running. What the market did while it ran was never up to the process at all.
Pricing
Crypto trading bot uptime isn't a paid add-on here. Every tier ships the same recovery primitives, Windows Service integration, Docker restart-policy compatibility, and the alert triggers that tell you when something needs attention. Starter at $19.99/mo covers signals and DCA on one live instance, the right scope for a single machine you're keeping an eye on yourself. Pro at $49.99/mo adds the 15-indicator strategy builder and copy trading across 5 live instances. Enterprise at $89.99/mo adds multi-machine management and Docker plus VPN support across 10 live instances, built for the proxy's per-instance status tracking to actually earn its keep across real distance.
Underneath this feature sits the same engine that runs everything else, cava-signals, 15 real-time indicators, the AI strategy builder, DCA, grid, futures, copy trading, backtesting, paper trading, and tax exports, self-hosted on a machine that's yours. See how TradeArmor is built before deciding which restart policy and which host is worth setting up around it, or compare the three tiers and pick the one that matches how many instances you're actually keeping alive.
Past performance is not indicative of future results. Signals are algorithmic outputs, not personalized investment advice.