← Blog

Running a bot 24/7 is an ops problem, not a strategy problem

People obsess over the strategy. Fair — it’s the fun part. But after running bots for a while, my scars are almost all from the other 80%: keeping the thing alive, on the right clock, doing the right thing when the market opens and nobody’s watching.

A few that actually happened:

The clock bug. A bot scheduled by cron, on a server in one timezone, with the cron times written for another. It ran every day — just shifted by hours, quietly missing the market open it was built around. The strategy was fine. The clock was lying. Nothing in the P&L screamed “timezone”; it just underperformed for no obvious reason. Always pin your timezone explicitly and prove the bot wakes up when you think it does.

The end-of-day failsafe. A position that should’ve been flat by the close stayed open because the “session close” event never fired — the closing bar got skipped. One missed flatten can blow a prop-firm rule overnight. Now there’s a hard, time-based “be flat by 15:55” that doesn’t depend on any one bar showing up.

The silent disconnect. A bot that “ran all day” but had quietly dropped its data feed at 11am and spent the afternoon making decisions on stale prices. From the outside it looked alive. Heartbeats and reconnect logic are not optional.

The pattern: the failures that cost the most aren’t strategy failures. They’re a process that died, a clock that drifted, a connection that dropped — boring infrastructure problems wearing a trading-loss costume.

Your edge is only worth what your uptime lets you collect. Treat the bot like production software, because that’s what it is. The strategy earns the money; the ops decide whether you keep it.

Activate your code →