Bugs found. Bugs fixed.

After today's two earlier fixes to the losing-streak protection, a 5th loss still got through - and this one tipped the day from "gave back most of the profit" to an actual net loss (-$16.64, down from a $82.96 peak). Worth understanding why neither of today's earlier fixes caught it.

The answer: this 5th loss wasn't part of a losing streak at all. It was one standalone losing trade, on its own, after an earlier streak had already reset. Every fix we'd made so far only watches for consecutive losses in a row - by definition, it can never catch a single isolated loss that happens to be the one that tips a good day into a bad one.

So we built a genuinely different kind of guard: rather than watching for streaks, watch the day's running total directly, and pause new trades for the rest of the day once that total drops to a small real dollar floor - regardless of whether it got there via a streak or one bad trade. Tested against the full real trade history across a range of dollar amounts, and this was the clearest result of the entire day: a solid, consistent improvement across a whole range of nearby dollar values, not just one lucky number - real evidence this is a genuinely different, more complete kind of protection, not a variation on the same idea.

Same as everything else today: simple, reversible, practice money only, ready and tested but not yet running live - we restart these ourselves.

After tightening the losing-streak safety net earlier today, we checked back in and found it hadn't been quite enough: a 4th, separate losing trade fired a few hours after the safety block from the earlier 3-loss streak had already timed out and lifted. Real numbers: the day's profit had peaked near $83, and after this 4th loss it was down to just a few dollars net - practically the whole day's gain, gone.

We first tried modeling a different kind of guard: pause new trades for the day once profit has been given back by some percentage from its peak. Tested several percentages against the real trade history, and the results were inconsistent - some percentages helped, one actually made things worse, on too small a real sample to trust any single number. We didn't ship that.

Instead we improved the mechanism already proven to work: rather than a fixed multi-hour pause after a losing streak, the pause now extends through the rest of that trading day (with the original fixed length as a minimum, so an early-day trip still gets proper protection). Tested against the full real trade history, this version would have improved results by just over $100 - a much cleaner, more consistent real signal than the percentage-based idea. Same as the earlier change today: simple, reversible, practice money, and we'll keep checking real results against what the history predicted.

Asked to look into why this bot's balance had climbed nicely through the morning and then dropped back partway. The real pattern: two genuinely good trades built up real profit, then three quick losing trades in a row on fresh entries gave back a meaningful chunk of it before anything stepped in. The bot still ended the stretch up overall, not flat - but a real reversal worth checking.

Good news first: this bot already has a safety mechanism built for exactly this - after a set number of losses in a row on the same side, it blocks new trades on that side for a few hours. It worked correctly and stopped things after the third loss. The question worth asking was whether "three" is actually the right number, or just a reasonable guess from when it was built.

It was a guess at the time - there wasn't enough real history yet to check. There is now. We went back through every real instance where this bot had already lost twice in a row on the same side and asked what happened on the third attempt: it was also a loss over 70% of the time, and added up across every one of those third attempts, the real result was a net loss. In other words, the data says stopping after two losses rather than three would have done better, not worse.

We tightened the setting accordingly. It's a simple, reversible config change on a practice account - we'll keep watching real results to make sure they track what the historical data predicted.

Yesterday's Bitcoin order-rejection fix (the scientific-notation bug) went live, and we confirmed it working on four real trades with zero repeat errors. While reviewing activity afterward we noticed a different, much more frequent rejection - "insufficient balance" - showing up across many different coins, which we'd assumed was just normal, harmless contention between simultaneous buy attempts sharing one account balance. We were asked to actually check that assumption rather than keep waving it off, and it turned out to be wrong.

The real cause: when our sizing works out that a trade is too small to meet the exchange's own minimum order size, the code bumps it up to that minimum and places the order anyway - without ever checking whether the account currently has enough spare cash to actually cover that minimum. This happens routinely, not rarely: if an earlier trade in the same scan already used up most of the available balance, the next coin's calculated trade size comes back small on purpose, correctly reflecting what's left - and our own code was then forcing it back up past what was actually available, guaranteeing the exchange would reject it.

We wrote a test that reproduces the exact real rejection first (confirmed the old code really does attempt - and fail - the doomed order), then fixed it with one real check: look at the actual available balance right before bumping up to the minimum, and skip cleanly if it genuinely isn't enough, rather than trying anyway. Normal trades with enough balance are completely unaffected. Same as yesterday's fix, this one is ready and tested but not yet live - we restart these bots ourselves.

This bot has had the most stubborn real decline in our whole fleet - two separate, thorough rounds of testing-tool tuning (dozens of setting combinations each time) found nothing that would have fixed it. Rather than try a third round of the same kind of test, we went straight to the real trade history instead and split it a different way: not by setting, but by how each trade actually ended.

The real split is clean: trades that reach any profit-taking step along the way win 86% of the time and are solidly profitable overall. Trades that get fully stopped out - about 3 in 10 of all real trades - lose 100% of the time, no exceptions, and account for the entire real loss. In other words: the bot's entry decisions are genuinely good. The whole problem is concentrated in how often a trade never gets the chance to take any profit at all.

We'd already made one live change three weeks ago aimed at exactly this - loosening how much profit gets locked in early, specifically to soften the blow when a trade does get stopped out. Checking real results since: it worked, on the exact thing it was meant to fix - the ratio between a typical loss and a typical win improved by nearly half. It hasn't yet turned the bot fully profitable, but there's only a small number of real trades to judge it on so far.

The honest bottom line: our own testing tool has repeatedly failed to find what a three-week-old live change already shows working for real. That tells us the tool itself still isn't trustworthy for this bot, not that there's nothing left to find. We're keeping the recent change in place rather than reverting it, and we're done running more test-tool sweeps here until the tool itself is fixed properly - testing against a tool that can't reproduce reality isn't testing.

Our internal monitoring flagged this bot as "drifted" - a cheap early-warning check, not a verdict on its own. Before touching anything, we re-ran our own stricter, real backtest on fresh data to see if the warning actually held up.

First, some good news buried in the process: a threshold fix from yesterday that we'd logged as "still waiting to take effect" turned out to have already gone live a day earlier than we realized - one loose end we can now close out properly.

With that fix confirmed live, the fresh real numbers showed a genuine reversal: buying-the-dip, which had been the right call on this instrument for over two months, is now clearly the losing side, while selling-the-rally has flipped to clearly winning. Our first instinct was a middle-ground fix - allow both directions rather than pick one. We caught ourselves before doing that: we'd already tested exactly that combination months ago and found it was worse than picking a side, for a specific real reason - a losing direction drags down a winning one, it doesn't just cancel out. So instead we made the same kind of call we made back then: pick the side the real data supports, fully.

Where it's honest, not perfect: this bot has traded very little the last three weeks, so we don't have enough very recent trades to double-check this specific call the way we normally would before flipping a live setting. We decided to act on the strength and consistency of the longer-term real numbers anyway, rather than wait indefinitely for more data that may not arrive soon - but we're saying so plainly rather than presenting this as a fully proven change. It's demo money either way, and easy to reverse if the next few weeks say otherwise.

While checking recent activity across our real-money bots, we noticed one of our crypto bots kept hitting a rejection from the exchange specifically when trying to trade Bitcoin - never other coins, just Bitcoin, over and over.

Traced it to a subtle number-formatting issue. Our code correctly works out the exact right trade size using precise decimal math, but right before sending the order, it was converting that number into an ordinary computer "float" - and for a very small quantity (which is normal for Bitcoin, since one Bitcoin costs six figures), that conversion can silently switch the number into scientific notation, like turning "0.00004523" into "4.523e-05". That's a perfectly valid number to a computer, but the exchange's order form doesn't accept that format and rejects it outright. Other coins we trade are priced low enough that their quantities rarely fall into that trap - which is exactly why this had gone unnoticed.

We wrote a test that reproduces the exact real failure first, confirmed it actually fails the way we thought, then fixed the formatting so the exact right number is always sent in plain decimal form, no matter how small. All existing tests still pass. Because this touches the actual order-placement code for a real-money bot, we're treating the fix as ready-to-go rather than already live - we restart these bots ourselves rather than have it happen automatically, so real trades keep the same order-placement code until that happens on our own schedule.

Following straight on from the limitation we described below - our forex bot's test can't fully reconstruct two of the signals it actually reacts to (market sentiment and broader economic context) - we went and tried to build both anyway, rather than just noting the gap and moving on.

Sentiment turned out to be genuinely reconstructable: we rebuilt a real historical record of it using the exact same formula the live bot itself uses, and checked it thoroughly against synthetic test cases before trusting it. Economic context turned out even easier than expected - the underlying government data source keeps a full, freely available historical record going back decades, which we hadn't realized going in.

We plugged both into the test and ran a careful before/after comparison. The honest result: neither one changed anything. The real sentiment numbers, once reconstructed, are almost always too small to cross the threshold the bot itself requires before treating sentiment as meaningful - so it mostly stays neutral anyway, gap or no gap. And the economic-context reading has simply sat in the bot's own "no strong signal either way" zone for its entire recent history, regardless of any data we could feed it.

So: two real, working pieces of testing infrastructure built and verified, and the honest conclusion is that they don't move the needle on this bot's testing gap right now - not because we built them wrong, but because the real underlying numbers are currently too muted to matter. We're logging that plainly rather than presenting "we built it" as "we fixed it." No live setting was touched.

After finding and fixing several testing-tool bugs on our practice bots this week, we checked whether our one real-money forex bot had the same problems. It trades over 20 currency pairs, and its own testing tool hadn't been refreshed in over a year.

First, we worked out its real recent profit and loss properly. Our first attempt at adding it up came out as a scary-looking large loss - and we caught, before reporting it, that the number was nonsense: it was mixing raw amounts from currency pairs that settle in completely different currencies (some in Japanese yen, some in US dollars) without converting any of them to a common one. Yen amounts look huge next to dollar amounts purely because of the exchange rate, not because they represent bigger real money. Done properly, using the same real currency-conversion logic our own bot already uses elsewhere, the real number was a real but modest loss - a small fraction of the scary first number, and in line with what we already knew about this bot's performance.

Then we found four real, separate bugs in the tools used to test this bot, similar in spirit to what we found on our practice bots: it was quietly pointed at the wrong server address the whole time (meaning it had likely never successfully refreshed its own data), it never captured the real gap between buy and sell prices, a timestamp format it never expected would have crashed the very first time it tried to fetch more data than one request could hold, and its own trade-simulation logic used a rough guess for that price gap instead of a real one. We fixed all four and used the repaired tool to pull half a year's worth of genuinely fresh, real data.

Where it stands: once the tool actually worked, it revealed something we can't quickly fix rather than a bug we could. This bot normally needs agreement from several different signals before making a real trade - market sentiment and broader economic context among them. Our testing tool can only ever reconstruct one of those signals from historical prices; the others simply don't have a historical record to replay. So even with every bug fixed, our test still only sees a fraction of what the real bot actually reacts to. We're not going to pretend a partial test tells the full story - we're logging this as a real, currently-open limitation rather than a solved problem, and no live setting was touched while investigating it.

Earlier today we found that our sugar bot's real stop-losses consistently close a bit worse than the number they're set to - a real execution cost, not a bug in the setting itself - and said we hadn't built it into our testing tool yet. We went back and did that.

We measured the real gap precisely from nine real closed trades, built it into the test as a fixed, calibrated cost applied only at the moment a stop genuinely fires, and checked the result against real trading: our test's simulated stop-losses now land within a couple thousandths of a percent of the real ones. That part worked exactly as intended.

What it also did was correct something we'd reported earlier the same day. Before adding this real cost, our test had shown this bot's more recent trading history as a real improvement - modestly profitable where the older history wasn't. With the real cost properly included, that same recent period is actually still a small loss. The earlier reading wasn't wrong on its own terms, it just hadn't accounted for a real expense yet - and once it did, the improvement mostly disappeared.

A mistake we caught before it reached anyone: rechecking two of our trading-rule combinations against the improved test, we ran two separate checks at the same time to save time - and got two different answers for the exact same combination. Tracing it down: both checks were quietly overwriting the same temporary file behind the scenes, so running them together corrupted both. We fixed the underlying cause (each check now uses its own private file) everywhere we use this kind of test across our whole fleet, confirmed none of today's other results had actually run into this, and redid this specific check properly, one at a time. The honest answer, done correctly: nothing we tested fixes this bot's real decline. We're not going to pretend a coincidence of timing was a real finding.

Wrapping up today's fleet-wide check with our S&P 500 bot and our Dow-tracking bot.

The Dow bot had the same stale-data problem we found on the S&P 500 bot earlier today: a data-refresh tool and its testing tool were quietly looking in two different folders, so refreshing the data never actually reached the file the test used - over two months stale. Fixed the folder mismatch and the same sampling-rate issue found elsewhere today. We'd flipped this bot from betting on a rise to betting on a fall earlier in today's work, and its real trading record is too short to judge that yet - almost every real trade on file is still from before the switch. Testing the new setting against the full real historical record instead gave a clear, encouraging answer: a real, strong, improving pattern, the same good outcome we found checking our Russell 2000 bot the same way.

The S&P 500 bot showed a real, if mild, recent softening - not dramatic, just a shift from modestly profitable to roughly breakeven. We tested the same fix that worked well on two other bots today (loosening how strict its entry condition is). It technically passed our test on paper, but only barely - the improvement was a few dollars on a couple dozen trades, well within the range of ordinary noise rather than a real signal. We're not applying it. Reporting a technicality as a fix just because we went looking for one would be worse than reporting nothing.

Where this leaves the fleet-wide review: real bugs fixed across essentially every bot we checked, one clear real fix found and applied, one thin fix applied with the thinness stated plainly, and two real declines left as open questions because nothing we tested actually explained them. That's the standard we're holding ourselves to throughout - not everything gets a tidy resolution, and we'd rather say so.

Continuing our fleet-wide review, we checked our Russell 2000 bot and our Nasdaq bot next - each for the same kinds of real problems we'd already found elsewhere today.

The Russell bot came back clean. We'd flipped it from betting on a rise to betting on a fall a few weeks ago, and there hadn't been enough real trades since to know if that was the right call. Testing that same setting against a much longer stretch of real historical prices instead - not just the short real record so far - gave a clear answer: the setting genuinely holds up, consistently, across two independent halves of history, and even gets stronger in the more recent half. Nothing to fix here; this one just needs more time trading for real to build its own track record.

The Nasdaq bot had a real, specific question sitting open since two weeks ago: after a real cluster of losing trades, we'd added a rule blocking its own most-confident trades from firing - a genuinely surprising real pattern where confidence and correctness were pointing opposite ways. But we couldn't properly test that rule at the time, because this bot's own testing tool had the same 5-times-too-few-samples problem we found on other bots today. Fixing that first finally let us check it properly - and it turns out that confidence-blocking rule really has been working the whole time, we just couldn't prove it until now. On top of that, the same real recent decline pattern we found on our silver bot showed up here too, and the same fix helped - though far more modestly, real but thin, and it means trading noticeably more often for a smaller edge.

Honest note: two real fixes landed today with very different confidence behind them. Silver's fix was a strong, clear improvement. This Nasdaq one is real and split-half-consistent, but barely - we're applying it with that clearly stated, not dressed up as more than it is.

Two of our bots - silver and sugar - have both been showing a real recent decline in our earlier reviews today. Since both were originally built from the same starting template, we checked whether they were failing for the same reason rather than treating them as two separate mysteries.

First, a real spread-related bug on the silver bot, the same kind as one we'd already fixed elsewhere today: its testing tool had never captured the real gap between buy and sell prices, and that gap turned out to matter enormously - a tiny change in the assumed number swung its simulated trade count from a normal amount all the way to zero. Fixed it the same way, using the bot's own real historical prices instead of a guess. With that corrected, the real decline was still there - if anything clearer than before - so this wasn't hiding a false alarm, just making the real picture sharper.

Both bots, we noticed, had been running identically-set trading rules since the day they were built - never independently checked against each other's own real price history. Testing whether loosening those shared rules helped: on the silver bot, it did, clearly and consistently across both halves of its history independently. On the sugar bot, tested the exact same way, it changed nothing - the same fix that worked for one did nothing for the other.

What we did: loosened the silver bot's entry condition to match what its own real history actually supports, real-tested across two independent time periods before trusting it - a real, if large, increase in how often it now trades, applied with that fully in mind. Left the sugar bot's settings untouched, since nothing we tested earned its place - we're not going to report a guess as a fix just because we went looking for one. Its real decline remains a real, honest open question rather than something today's testing could resolve.

Continuing today's fleet-wide review, we turned to our oil bot - currently the biggest real loser in our lineup. Checking its testing tool against real trading turned up the same 5-times-too-few-samples issue we'd already found and fixed on two other bots today. But fixing that alone didn't add up: the rebuilt test still didn't agree with real trading, and a second real issue turned up alongside it - this bot's test had never captured the real gap between buy and sell prices either, using a rough guess instead. That guess turned out to matter enormously here: nudging it by a tiny amount swung the test's trade count from zero to dozens. We fixed that too, pulling the real historical figure directly from the same real market data.

Even with both fixes in place, the numbers still didn't line up - the rebuilt test now showed a real, consistent profit, while real trading showed a real loss, over what we thought was the same stretch of time. Before writing that up as a mystery, we went back to the raw real trade records instead of trusting our own summary of them. That's what caught it: this bot had actually been betting on both a rise and a fall at the same time for about six weeks, even though its current setting only allows betting on a rise. We'd been comparing the rebuilt test - which only knows about betting on a rise - against a real record that mixed both. Once we compared it only against the period where the real setting and the real trading history actually match, the two finally agreed: both showed a small real loss, on almost exactly the same number of real trades.

Where this leaves it: the testing tool is fixed and trustworthy now, but the honest real evidence for this exact setting only goes back about two weeks - too little yet to say whether the loss is real and durable or just a rough patch. We're not tuning anything further until more real evidence comes in, and we're flagging our own near-miss here on purpose: the fix that looked complete after the first correction wasn't, and only checking the raw records - not trusting our own arithmetic on top of them - caught the second problem.

Closing out something we flagged earlier today: once we found the fabricated placeholder number on our gold bot, then again on two more bots while chasing a separate issue, we went back and checked every remaining bot in our fleet for it directly, rather than waiting to stumble onto it again one at a time.

It was there in all of them. Every one of our practice-account bots - oil, silver, soybeans, sugar's Dow-tracking sibling, and our Nasdaq bot - had the exact same fake number standing in for real trading-activity data, all built from the same original template. We checked each one individually before touching anything: does this bot's real decision-making actually use this number? In every single case, no - each bot measures real market volatility a completely different way, and never reads the fake number at all. So this had been sitting dormant and harmless in all of them, not quietly costing anyone money, but a live risk waiting for a future version to start using it without anyone noticing it was fake.

Fixed everywhere: all five now pull their real trading-activity number from the same live market-data source already used elsewhere in each bot, verified against the real feed for every one before moving to the next. The old fake number only kicks in now as a documented last resort if that real fetch ever genuinely fails, with a clear warning logged - not silently pretending to be real data forever, the way it did before today.

After finding and fixing the sugar bot's testing-tool blind spot earlier today, we checked whether the same issue existed on our other bots that use a similar strategy style. It did, on two more - our S&P 500 bot and our Russell 2000 bot - each confirmed independently with real numbers before assuming the pattern just carried over.

For the S&P 500 bot, testing at the old resolution caught only a third of the trades it actually makes in real life over the same stretch; rebuilding the test at finer resolution brought that to essentially all of them, and the profit figures lined up closely with real trading too. For the Russell 2000 bot, we found something else first: its real trading switched from betting on a fall to betting on a rise partway through the period we were about to test, and we almost compared the rebuilt test against the wrong direction entirely. Caught it, restricted the comparison to the period that actually matches how the bot trades today, and the same fix closed most of that gap here too - though with so few real trades since that switch, we're not reading much into the smaller amount left unexplained yet.

We also went looking specifically for the fabricated placeholder number from earlier today's gold-bot fix, since finding it twice already suggested it might be a shared building block across more of our bots. It was - in both of these, and in every other bot we checked. Confirmed none of them actually use that number for real decisions (each one's real volatility measure comes from somewhere else entirely), so this was dormant everywhere we found it, not quietly costing anyone money - but we fixed it in all of them anyway so it can't become a live problem later.

One more small thing surfaced along the way: the S&P 500 bot's testing tool had been quietly running on data from over two months ago, because a data-refresh tool and the testing tool were looking in two different folders for the same file. Re-running the refresh looked like it should have kept things current - it just never reached the file that mattered.

We've known for a while that this bot's real trading and its own historical testing tool told two different stories - real trading showed roughly a third as many trades as the testing tool predicted for the same stretch of time, and we'd flagged the cause as unresolved. Chasing today's soybean-bot investigation into other bots turned up the same instrument, so we finally dug in properly.

Root cause: this bot checks the market every 60 seconds in real life, but its testing tool only checked once every 5 minutes - about five times fewer chances to catch a brief price swing that reverses before that 5-minute mark. Since this bot's strategy is specifically built to catch those brief swings, the testing tool was structurally blind to most of what actually triggers a real trade. Rebuilding the test at 1-minute resolution instead closed that gap almost completely - real trading and the rebuilt test now agree on how often trades happen, where before they were off by roughly 4-5x.

Partway through, we caught ourselves nearly repeating a mistake from earlier today on a different bot: comparing the rebuilt test against real trades without accounting for a real change in which direction this bot was allowed to trade partway through the test period. Corrected for that before trusting any of the numbers - a good reminder that a more accurate testing tool doesn't help if you still feed it the wrong real-world assumptions.

With that fixed, the rebuilt test and real trading now finally agree on the *direction* of the result too - both show a real loss over the same period, where the old test had confidently shown a profit. We also found a real, measurable, separate issue while comparing the two side by side: when this bot's stop-loss fires for real, it consistently closes 0.3-0.5 percentage points worse than the number it's set to - a real execution cost the old test never accounted for, since it assumed every stop-loss closes at exactly the price requested. That's a concrete, evidenced lead for future work, not yet built into the test.

Also fixed along the way: found the exact same fabricated placeholder number we fixed on our gold bot earlier today, living in this bot's data feed too - confirming both were built from the same original template. Checked first whether it actually affects this bot's real decisions the way it did on the gold bot: it doesn't, this bot's own logic never reads that particular number, so it was a dormant copy-paste bug rather than something quietly corrupting real trades. Fixed anyway so it doesn't become a live problem if a future version starts using it.

Our soybean bot hit its hard stop-loss twice within three days, after going seven weeks without one. Looking at its full real trading history: an 80% win rate, but the rare losses were roughly four and a half times bigger than the frequent wins - the kind of shape where you can be right most of the time and still lose money overall.

We checked first whether the bot should simply be trading the opposite direction - a fair question after two losses in a row - but a real historical test said no: the long-term evidence still clearly favors the direction it's already trading, and the recent sample was too thin either way to trust as a reason to flip. So the direction wasn't the problem. The actual mechanism was: this bot only locks in any profit protection once a trade has moved a small amount in its favor first; a trade that goes against it from the very start gets no such protection and rides all the way to the full stop-loss.

We tested 72 different combinations of the relevant settings against real historical prices, and the combination that looked best over the full test period turned out to be misleading once we split that period in half and checked each half on its own - a trap we specifically test for. The full test period was hiding something: with today's actual settings, the more recent half of history alone is already a net loss, which lines up exactly with the two real stop-losses that just happened. That recent decline was the real problem, not the direction.

Fix: the one change that held up in both halves independently - not just the combined average - was letting a trade move a bit further in its favor before that first layer of profit protection switches on. That change turned the recent-history loss into a small real gain, and barely affected the older, already-good half. We're not overstating this: it's a modest fix for a recent decline, not a transformation - the same real test also showed this bot's worst-case losses have gotten larger recently regardless of any setting we tried, which looks like real increased volatility in the market itself, not something a settings change fixes.

While double-checking that two other fixes below were holding up, we noticed hundreds of repeated failures trying to send ourselves a phone notification about the gold bot's activity - the kind of alert that tells us a trade opened or closed.

Cause: these notifications only go out when something actually happens, not on a constant schedule, so the connection used to send them sometimes sat unused for a while. Occasionally the other end quietly closed that connection during the gap, and the next attempt failed immediately, before it ever really got going - not a real outage, just a stale connection being reused.

Fix: a failed attempt now automatically retries once on a fresh connection instead of giving up right away, the same approach we already use for our real market-data connections. Confirmed with a real test notification, delivered successfully. This only affects whether we get pinged about the bot's activity - it never touched the bot's actual trading.

While watching the console for something unrelated, we spotted a live warning flagging one specific number as far more extreme than anything else the model was looking at - and it kept happening on virtually every single check-in, not as an occasional blip.

Traced it back: that number, meant to represent how much trading activity was happening in the market, had always been randomly generated on every real live check-in - never actually connected to anything real, regardless of whether the rest of the market data was correct. The model, however, had been trained on the true historical version of that same number, which sits on a completely different scale. That means every real trading decision this bot has ever made included at least one input that was pure noise, not real information.

Fix: now fetches the real version of that number directly from the same real market-data source already used elsewhere, matching the exact time window the training data itself uses. Confirmed live: the number now sits in a normal, expected range instead of standing out as an extreme outlier every time.

We noticed the gold bot hadn't traded in days and dug in. The bot's own model hadn't stopped working - it had essentially decided not to want to trade at all, sitting in "hold" the vast majority of the time.

Root cause: one of the model's inputs - the small real-time gap between the buy and sell price - gets converted into a number the model can learn from using a scale that itself gets learned from training data. That scale turned out to be badly broken: the training process had never had access to a real historical version of that gap, only a single fixed stand-in value used for every training example, so the model was trained believing that gap never moves at all. When the real gap moved even slightly during live trading, it registered as a number hundreds of times more extreme than anything the model had ever seen, and the model reacted by refusing to trade. We confirmed this was the exact cause by matching it precisely against the bot's own live activity log.

We fixed the immediate problem using 2,000 recent real readings to recalculate the broken scale, and added a general safeguard so any input's learned scale being suspiciously close to zero gets caught automatically from now on. But that still left the deeper question: why did training never have the real number to begin with? Traced it to the data-collection step itself only ever requesting the mid-point price, never the actual buy/sell gap - fixed that too, then ran a full real retrain on properly collected data.

Honest result: we compared the retrained candidate against the model currently trading, on real, unseen historical data. The candidate won on every measure we track - smaller loss, better win rate, smaller worst-case drawdown - but it was still not profitable over that stretch, so our own promotion rule correctly declined to switch to it. Real improvement, not yet a fix for profitability itself - we're not overriding that rule to make the story sound better than it is.

Three of our crypto bots share a strategy that only buys when the wider market is fearful - a deliberate, contrarian approach. For five straight days the market did the opposite of fearful, so all three sat in cash the entire time. Fair question raised: what's the point of that if it means missing the exact stretch everyone else is making money in?

So we built a real historical test - not a guess - to find out. It confirmed something uncomfortable: neither of the two approaches these bots have ever run actually captures a rising market. One sits out entirely, by design. The other, an older approach gated on price volatility instead of market mood, does keep trading through a rally - but when we replayed it against real historical prices for the exact days in question, it actually lost money there too. Both existing approaches turn out to be variations on the same idea - buy dips, sell bounces - just triggered by different signals. Neither one is built to ride a trend upward.

We built a genuinely different, third approach specifically to test that gap: buy strength once a real uptrend is established, hold it as long as the trend continues, and only sell when the trend itself breaks - no fixed profit target capping the ride short. Replayed against real historical prices, it did capture real gains during the exact stretch the other two missed or lost money in. The first version also traded far too often to survive real exchange fees once we accounted for them honestly, so we added a filter requiring a trend to be genuinely confirmed before acting on it, cutting the trade count by roughly 90% - real-tested twice more, over three weeks and then three months of history, checking the first half of that period against the second half independently rather than trusting one lucky-looking total.

What we did: one of the three bots is now running this newly built approach live, at its normal size, so we can watch it against real market conditions rather than trusting historical replay alone. The other two bots are unchanged. This is a live observation period, not a claim that the new approach is proven - the same real-evidence-before-trust standard we hold every change on this log to.

Someone reviewing our fleet dashboard spotted two crypto trades showing $2.37 and $3.01 in profit and flagged that the numbers didn't look right, then sent us the exact same two trades straight from our trading software's own screen - which showed 2.37% and 3.01% gains, with the real dollar amounts sitting at $0.31 and $0.21. Nearly ten times smaller than what our own dashboard had shown.

The cause: our trading software logs each closed trade with a field literally called "profit" - except for this bot, that field is actually a percentage, not a dollar figure. Our dashboard had been reading that percentage straight into the dollar column for every single trade this bot has ever closed. This was a display bug on our own internal monitoring tool, not a problem with the trades themselves or the money involved - the bot bought and sold correctly the whole time, and its real balance was never wrong. It just looked far more profitable on paper than it actually was.

Our first attempt at fixing it also came out wrong - we tried rebuilding the real dollar figure from other numbers in the same log entry, and got a wildly incorrect negative result, because we picked the wrong field to represent how much of the position was actually being sold in that specific trade. We caught this by checking our fix against the real numbers from the trading software's own screen before trusting it, the same standard we hold every fix to.

Fix: the dashboard now calculates real dollar profit directly from price and quantity, matching the trading software's own figures to the second decimal place, verified against the exact trades that were flagged. This was a read-only reporting fix - it required no changes to the bot's actual trading and no restart of anything live.

Four days ago we gave our gold bot the ability to close a losing position early when its own model was highly confident it was reversing, instead of waiting for an older safety rule that only protects a trade once it's already profitable. We tested it carefully against months of real history first and it looked good. Reviewing the actual trades since, though, it was closing almost every single position within a minute or two of opening - not the occasional rescue it was designed to be, but the dominant way nearly every trade ended.

Our first theory was that the fix simply wasn't doing what the test said it would - a worrying thought, since it would mean the whole validation was meaningless. That turned out to be a red herring: a logging setting meant to keep the test's output readable was also hiding the evidence that the mechanism was working correctly during testing, at a much calmer rate than what we were now seeing live. The real difference: our bot checks in with its model roughly once a minute while trading for real, but the test only checks in once every five minutes - so live gets five times as many chances for a fleeting, not-yet-reliable reading to trigger an early exit before a trade has had any real time to prove itself.

Fix: a new rule requires a position to actually be held for a minimum stretch of real time before this early-exit ability can trigger at all - deliberately set to match the five-minute spacing our own testing already uses, so the fix costs nothing against the historical results that justified it in the first place, while bringing live behavior back in line with what was actually proven to work.

Our gold bot bought at what turned out to be a short-term high, and the price fell steadily for the next ten minutes until a stop-loss closed it for a small loss. What made this worth digging into: our bot's own model actually recognized the reversal almost immediately, flagging a strong urge to exit within the first minute. It just wasn't allowed to act on that instinct - a safety rule requires a position to first move into profit before its stop-loss is allowed to tighten and protect it, so a trade that goes wrong right out of the gate has no such protection until it's too late.

We tested two different fixes against months of the bot's own real trading history before touching anything live, and only kept the one that actually earned its place. The first idea - loosening the trend check we added a few days ago so it ignores weak signals - made results worse at every setting we tried, because even a weak signal turns out to be more useful than no signal at all. The second idea - letting the model act on its own high-confidence "this is reversing" read even before the usual safety rule would normally allow it - held up: tested at a dozen different confidence bars, every single one beat doing nothing, cutting total losses and worst-case drawdown by roughly a quarter in the strongest range.

Fix: the bot can now close a losing position early when its own model is highly confident it's reversing, instead of waiting for a safety rule that assumes the trade is already working. Only the version that proved itself on real historical data was enabled; the trend-check idea that didn't help was built, tested, documented, and left switched off.

After giving our gold trading bot an independent trend check that overrides it when it wants to trade against the bigger picture, we asked a reasonable follow-up: should our other eight practice-account bots get the same safeguard, since they're built from the same base code?

We tested it properly instead of guessing - replaying each bot's own real trading history to see what would have happened with the safeguard turned on. The answer came back clean and consistent: no. For every one of the eight, the trades that go against the bigger-picture trend are actually the more profitable ones, not the less profitable ones. Adding the safeguard would have made all eight worse, in one case turning a real profit into a real loss. These bots make their money differently from the gold bot, and a fix built for one doesn't automatically transfer to the others just because they share code - we checked, and it doesn't.

Building that test surfaced something unrelated but more serious: one bot's test-replay tool was found to share the same storage file as its real, currently-running trading process - and a test run had overwritten that file with made-up numbers while the real bot was holding an actual open position. The running bot itself was never confused (it keeps its own copy of what it's doing in memory while it runs), but the saved record on disk was briefly wrong, and would have loaded incorrectly had the bot restarted before its next trade.

Fix: every bot's test-replay tool now writes to its own separate scratch file instead of the real one - four of nine already did this correctly; the other five (including the affected one) now do too. Verified directly: confirmed the real bot's own internal state was correct throughout via its live activity log, corrected the on-disk record to match, and confirmed the test tool now gives identical results when run twice in a row, which it hadn't before.

Our gold trading bot (a practice-account strategy, not real money) went about a day without placing a single trade, even though its own model was firing off very confident "buy" signals on a regular basis. Digging into why turned up two things happening at once.

The main reason turned out to be intentional: we'd recently added an independent check that looks at the bigger-picture trend and vetoes the model when it wants to go long into a broader downtrend. Gold's bigger-picture trend had stayed down while the model kept insisting on buying anyway - so the new check was correctly overruling it, over and over. That's exactly the behavior we built it for, and testing on real historical data already showed doing this removes more losses than it costs.

The second issue was a real bug, and it's what made the situation invisible: a separate, older safeguard - a minimum 90-minute gap between trade attempts, meant to stop overtrading - was quietly starting its 90-minute timer on ANY attempt old enough to try again, even one that got vetoed by the check above and never actually opened a trade. So one vetoed attempt was silently blocking every other signal for the next 90 minutes, with nothing logged anywhere to explain it - making it look like the bot had simply gone quiet for no reason.

Fix: that safeguard's timer now only starts after a trade genuinely goes through, never on an attempt that gets turned down. A turned-down attempt is also now logged with the reason, instead of vanishing silently. Verified directly: restarted the bot and confirmed the fix is live via the process's own start time versus the code's last-changed time.

The system that turns each completed trade into a shareable card and clip had one trade it could never process: a single partial close from a gold trade a month ago, whose matching "opened" record had already rotated out of that bot's trading log by the time this piece was reached. With half its information missing, the card generator crashed trying to read a trade side that was never filled in - and it crashed on this same trade every single time it ran, blocking everything queued behind it.

We also found a second, separate issue while digging in: a handful of cards were intermittently failing only when generated by our scheduled automatic run, not when run by hand - traced to the browser engine used for rendering occasionally not being ready in that specific automated context. That one cleared itself once we reproduced and re-ran it manually a couple of times.

Fix: the generator now recognizes when a trade's opening details are permanently unrecoverable and skips it cleanly instead of crashing. Verified directly: re-running the generator now completes with zero errors, where it previously failed every time on this trade. Cleared the resulting backlog of stuck cards down to zero across all tracked bots.

Our forex bot has a safety check that pauses all new trades for a short cooldown whenever it detects something worth double-checking with the broker - a sensible feature on its own. What we found: this pause had been quietly re-arming itself before ever expiring, continuously, for over 31 hours - across two separate restarts - so the bot never placed a single trade all day.

The real cause was a data-formatting mismatch. Our broker's timestamps carry more decimal precision than the standard library function reading them expects. When that function met one of these, it silently failed and treated the timestamp as "right now" instead of what it actually was - a stop-loss closure from over 32 hours earlier. That made an old, unremarkable event look brand new on every single check, resetting the pause indefinitely.

Fix: the timestamp reader now trims the extra precision before parsing, matching a fix already applied elsewhere in the same bot for the identical reason. Verified directly: the old timestamp now parses correctly and is properly recognized as more than a day old, so it stops resetting the pause.

While fixing the issue above, restarting the bot to test the fix surfaced a second, unrelated problem: its background machine-learning training process was crashing on startup every single time, before it could do any training. The main trading side of the bot - price monitoring, decisions, live positions - was never affected; this was isolated to the training process running alongside it.

The cause: a decorative emoji in the training process's startup message, combined with how Windows handles text in the background console it runs in, which doesn't support that particular character and crashes instead of simply skipping it. We've hit this same category of issue once before in a different part of our systems.

Fix: told the training process's console to handle any character it's given rather than crash on ones it doesn't recognize. Verified directly by restarting the bot and confirming the training process starts and runs normally.

Our forex bot only actively watches a rotating shortlist of currency pairs at any one time, based on which ones are currently performing best. That's by design. What we found today: when a pair drops off that shortlist, the bot was shutting down its monitoring for that pair entirely — including the safety nets on any trade it still had open in it. Three real positions had rotated off the shortlist days earlier and had been sitting completely unwatched since: no stop-loss, no take-profit, no trailing protection, nothing checking on them at all.

We caught this when the user asked why a profitable trade hadn't taken its normal partial profit — the honest answer was that nothing was checking it anymore. All three positions were still in real profit at the time, and were closed out manually as an immediate precaution while the fix was built.

Fix: any pair holding a real open position now keeps its full protection running for as long as that position exists, regardless of whether it's still on the active shortlist. The shortlist still controls which pairs can open new trades - it just can no longer switch off protection on money that's already in play. A second, related gap was found and closed at the same time: a pair that had already dropped off the shortlist before this fix existed wouldn't have had its monitoring properly restarted even after the first fix - both are now covered. Verified against the real account and backed by 18 new automated tests before being shipped.

Our gold-trading bot uses a machine-learning model to decide when to buy or sell. Today it went 6-for-6 wrong on the buy side while gold quietly drifted lower all day — and stayed just as "confident" in its own decision on trade six as it was on trade one. That's the real weakness we went looking to fix: the model's confidence score reflects how sure it is of itself, not whether it's actually right, and it has no built-in sense of the bigger trend or of its own recent losing streak.

We built two independent checks that sit alongside the model rather than inside it. The first compares every new trade against the broader hourly trend and blocks it if the model wants to buy into a clear downtrend (or sell into a clear uptrend) — a second opinion, not a replacement. Run against real historical data, this would have blocked all six of today's losing trades, and over our full trade history it would have cut total losses by roughly $2,068. To be honest about the tradeoff: it would also have blocked 186 real winning trades along the way — this reduces damage, it doesn't turn the strategy profitable by itself.

The second gives the bot a short memory: when it's already lost several trades in the same direction in a row, its confidence in the next same-direction trade gets quietly discounted before that trade is allowed through, using a losing-streak counter the bot already tracks.

Fix: both checks were built as optional add-ons, tested independently, and reviewed against the real numbers above before being switched on today.

Three of our crypto bots share one trading strategy that only trades when a specific market-mood signal lines up. That signal had been quiet for six days straight, then flipped on today — and because all three bots watch the same signal, they all opened dozens of trades within minutes of each other. That part is just how the strategy is built, and isn't itself a problem.

What we found digging into today's results: 81 trades closed across the three bots, and 78% of them lost money — one of the three bots lost every single one of its 21 trades. Almost all of them closed within about a minute of opening, which isn't how a normal losing trade looks.

The real cause: each trade has a safety-net stop that's supposed to tighten and lock in profit once a trade is actually winning. But on a brand-new trade that hadn't shown any profit yet, that safety net was quietly collapsing down to the exact entry price — meaning the very next tiny wobble in price, in either direction, closed the trade immediately, before it ever had a real chance to move in its favor.

Fix: the safety net now only starts tightening once a trade has shown a real gain. Before that, it uses the trade's normal starting cushion instead of collapsing to breakeven — the same behavior every other trade on these bots was always supposed to have.

We noticed this bot's trades cluster heavily in the early hours of the day and rarely show up later — so we checked the real numbers. Over the last 45 days, 64% of all its trades happened in a single 6-hour window, and on most days it hit its daily trade limit before later hours even had a chance. That part was real.

But while digging into why, we found the bot's own "daily limit reached" warning log was mostly lying to us. The code checked the daily limit before checking whether the bot was just repeating a decision it had already made (like reaffirming a trade it was already holding) — so every time it simply confirmed an existing position, that got logged as if a brand new opportunity had been blocked. In one real sample of 256 such warnings, 250 of them were this false alarm. Only 6 were genuine.

We also checked whether the early-hours clustering is a real edge worth keeping — pulling fresh real price data and comparing volatility by hour. It isn't: the quietest trading hours are exactly when this bot trades most, and the busiest, most opportunity-rich hours are when it trades least.

Fix: reordered the checks so the warning log only fires for genuine blocked opportunities, not routine reaffirmations. Also raised the daily trade limit to give the bot real room to act later in the day, since some days already showed it wanting to keep trading past the old limit. No change to the bot's actual trading logic — only to what gets logged and how much room it has.

After a planned restart, only one of this bot's eight best-performing currency pairs was still marked as "selected" for trading — the other seven, each with a long real track record, simply weren't in the list anymore. Nothing crashed, nothing logged an error; they just weren't there.

The real cause: the system that ranks pairs by real performance was reading from a working log file that gets automatically rotated (trimmed down) once it grows past a certain size — far more often than the 30-day performance window it was supposed to be judging pairs against. Right after the restart, that file only had a few hours of history in it, nowhere near enough to fairly judge seven pairs with months of real, solid results.

Fixed by pointing that ranking system at our durable, non-rotating trade record instead, so a routine file cleanup can never again wipe out months of real performance history from consideration.

Separately, while investigating this, we found our own durable trade record itself had gone missing — months of real trade history, gone, with no trace of what happened to it in any of our own code, logs, or system history. We couldn't find the cause. What we could do: rebuild it directly from the broker's own official record, which is the real source of truth anyway. We recovered 1,296 real trades this way, and fixed our safety-net process so it now keeps both records in sync going forward, regardless of what caused this.

This bot has a feature that reads public social sentiment as one input among several. It had gone quiet for over two months due to a lapsed subscription. That's now resolved, and real data is flowing again — we also trimmed how often it checks in, so the same subscription lasts longer.

The bigger question this raised: could we use this restored feed to make the bot's more advanced (AI-trained) decision-making actually sentiment-aware? Looking into it honestly, the answer is not yet. That AI model has never been trained on real sentiment data — the feed's outage means there's no real history to learn from, and getting it back today doesn't create history that never existed.

Rather than force a decision-making change on an untested foundation, we're doing the patient thing: quietly building a real, growing history of this data now, so that in a few weeks there's enough evidence to properly evaluate whether it actually helps — before it ever gets anywhere near a live decision.

Reviewing this bot's configuration, we found seven currency pairs manually excluded from trading — all switched off within the same 24-hour window months ago, with no note anywhere explaining the decision. Checking their real historical performance before that point: every single one had been a strong, profitable performer. Nothing in the data justified leaving them off.

Turning them back on wasn't as simple as flipping a switch, though. The system that ranks and picks which pairs actually get to trade only considers pairs that already have recent trades to judge — and a pair that's been switched off for months has none. So switching one back on wouldn't do anything: it can't get picked without recent trades, and it can't get recent trades without being picked.

Fix: built a bounded trial system. Re-enabled pairs now get a fixed, limited window — a capped number of trades or days, whichever comes first — at reduced size while they rebuild a track record. Once that window closes, they compete for a permanent slot on the exact same real performance ranking as every other pair, and can lose that slot again if they don't perform. All seven pairs are now back in this trial.

One of this bot's safety rules force-closes any trade that's been open for 24 hours, on the idea that if a trade hasn't worked out by then, it's better to cut it loose than let it drift indefinitely. The forex market itself closes every Friday evening and doesn't reopen until Sunday evening — but the 24-hour clock didn't know that. It just measured raw calendar time, not actual trading time.

The result: a trade opened on Thursday or Friday and still running into the weekend would have its clock quietly keep ticking through the entire ~48-hour closure. The instant the market reopened Sunday evening, that trade's "age" was already well past 24 hours — so it got force-closed immediately, at whatever price the market happened to land on after the weekend gap, regardless of how the trade was actually doing.

We checked this against real history instead of guessing: going back through this bot's own trade-by-trade logs, we found that of every 24-hour timeout that has ever fired, over half were these weekend-inflated ones — and on average they made almost exactly nothing (+0.003%), because they were really just a coin flip on the weekend gap. The genuine 24-hour timeouts (the ones that didn't cross a weekend) averaged +0.19% — a real, working rule getting undermined by a timing bug roughly half the time it fired.

Fix: the 24-hour clock now only counts time the market was actually open, using the same Friday-close/Sunday-open schedule the bot already uses elsewhere. Verified against the exact real trades that were affected before trusting it.

With the missing-trade bug above fixed, we had a complete real trade history for the first time and asked the harder question: is this bot's actual trading logic any good? The answer was more interesting than a flat yes or no. Every one of the bot's five trading strategies wins 79-85% of the time whenever a trade is allowed to play out normally — closing at a profit target, trailing a winning move, or timing out. None of them is meaningfully worse than the others.

But nearly half of all real trades — 46% — never got that chance. They hit a fixed protective stop-loss first, before the entry logic's real advantage could show up. That's not a strategy problem, it's a risk-setting problem: the stop looks like it may simply be too tight for how long these trades are typically held (we found a real trade that took over 55 hours to reach its normal exit).

We tried to test a wider stop the honest way — against real historical data first — and found our existing testing tool for this bot simulates a completely different kind of stop-loss than the one actually in use live, so it couldn't answer the question. Building a proper test that faithfully mirrors the real live logic would take real time to get right, and we weren't willing to fake that confidence on a real-money decision.

What we did instead: widened the stop by 50% as a deliberate, real live experiment — clearly labeled as such, not dressed up as backtest-proven. We're watching real results closely over the next couple of weeks and will reverse it if it doesn't help.

We compared our forex bot's own trade log against the broker's real transaction history directly, the same way we catch everything on this page. The two disagreed badly: our own log showed the account up for the week; the broker's own records showed it down. Digging in, 32 real trades from that week simply weren't in our log at all — and every single one of them was a stop-loss firing to cut a loss. Checking the bot's entire history, this has likely been happening quietly since it first went live: real protective stop-losses working exactly as intended, just never making it into our own bookkeeping.

We couldn't pin down the exact reason our real-time logging missed these specific closes in the time we had, so rather than leave it broken while we kept digging, we built something more durable: a background check that compares our own records against the broker's real ledger every 15 minutes and fills in anything missing, using the broker's own exact numbers, not an estimate. It doesn't matter why a trade goes missing in the future — this catches it either way.

Fix: the 32 missing trades from the past week have been added back using the broker's real data. Our trade log's numbers now match the broker's own count and win rate exactly. A small residual difference remains in the total profit/loss figure, traced to older records with a smaller, separate rounding issue — flagged for a follow-up look, not something we're treating as solved just because the big piece is fixed.

Real trades on this bot showed a losing trade costing roughly five times what a winning trade earned. The reason was structural: the stop-loss protecting each trade was actually set wider than the very first profit target meant to lock in a win — the opposite of how it should be weighted.

Before changing anything, we checked whether our offline testing tool for this bot could be trusted (two of our other bots failed that check today). This one passed — it generates roughly the same number of trades our real bot takes, for the same real market data. That gave us confidence to test properly: tightening the stop improved results across the bot's entire trading history and held up separately in just the recent weeks — the same two-part check we require before trusting any change like this.

Fix: stop-loss tightened to match the first profit target's spacing. Confirmed by real backtest, not just a live guess.

A routine review flagged this bot as showing no clear edge in either direction — rather than stop there, we broke down every real trade by how confident the model was when it opened it. The split was clean and backwards from what you'd expect: trades opened below a certain confidence level made money; trades opened above it lost money, and lost enough to account for the entire real loss on this bot.

We tried to confirm this against months of historical data first, the way we normally do, and couldn't — the same offline-testing gap we found on our sugar bot the same day turned up here too, generating far fewer test trades than the bot actually takes live. That's now looking like one shared bug across several of our bots rather than two unrelated ones.

What we did anyway: added a new kind of limit we've never used before — a confidence ceiling instead of the usual floor, blocking the bot's most-confident trades rather than requiring a minimum. Tested the logic in isolation first. It's a real but modest sample, and we're watching it rather than declaring it solved.

Reviewing why our sugar bot keeps losing more on bad trades than it makes on good ones led somewhere more fundamental. The real numbers are stark and simple: an average win of $10 against an average loss of $32.61 — a real trade needs to win about 3 times out of 4 just to break even, and it's only winning about 3 times out of 5.

Trying to find a better setting the way we normally do — testing it against months of real historical price data first — turned up something we didn't expect: our offline testing tool generates roughly a tenth as many trades as the bot actually takes live, for the exact same real market data and settings. That means every past "backtested" result for this bot, including the one that originally justified its current settings, was built on a tool that doesn't accurately mirror what the bot really does. We haven't found why yet.

What we did anyway: made two real, reasoned changes directly on our demo account rather than wait — increasing how much profit gets locked in on the first target, and tightening the stop-loss to match a value already proven on a different bot trading similarly noisy markets. Neither change is backtest-confirmed the way our other fixes are, and we're saying so plainly rather than dressing it up as more certain than it is. We're watching the real results and will adjust again once the testing tool itself is properly fixed.

Three weeks ago we built a safety switch for our gold bot: after three losing trades in a row on the same side, block new trades on that side for a few hours, on the theory that a model repeating the same mistake needs a timeout, not another chance. Reviewing it this week found it had never actually triggered once — including through a real three-in-a-row losing streak the night before this review.

The reason: most of this bot's real losses happen when a stop-loss fires automatically at the broker, not when the bot decides to close a trade itself. The safety switch was only ever watching the second kind. It genuinely couldn't see the exact pattern it was built to catch.

Fix: both ways a trade can close now feed the same tracker. Tested by replaying the exact real losing streak from the night before against the fixed logic and confirming it now trips correctly. Also found the safety switch's own code had never been saved to our version history since the day it was built — fixed alongside this change so it can't go missing again.

Three weeks ago a rigorous check found our Dow Jones bot (Spike) wasn't earning its keep on either side of the market and switched it off entirely, with the real numbers behind that call written up honestly at the time. That write-up sat un-backed-up on our own systems since the day it was made — a real gap in our own process, not this bot's fault — so when we came back to review it this week, we almost missed it and nearly turned the bot back on for the wrong reason (it looked like an accidental setting, not a deliberate one).

Once we found the original reasoning, we didn't just trust it blindly either: the exact data slice behind that three-week-old check no longer exists on our systems to check against directly. So we rebuilt the closest honest match we could, then checked three more ways on top of that — the bot's full trading history, the second half of it on its own, and its real live trades since launch. All four came back positive. Only the original check said otherwise, and we couldn't reproduce that result no matter which window we tried.

Fix: re-enabled the bot on its original design (long trades only), backed by four independent checks instead of one, and this time the full reasoning — plus the two real code bugs that write-up also uncovered along the way (see below) — is committed properly so it can't go missing again.

Two smaller, real issues turned up during the investigation above. First: one bot's stop-loss closes were being logged in raw pounds and mislabeled as dollars — the same class of bug we fixed fleet-wide on 2026-08-19 below, just one bot that had forked its code slightly earlier and never got the fix. Second: that same bot's own testing tool had a missing setting that silently sized every simulated trade down to zero, so every test anyone ran against it for weeks quietly reported "zero trades" instead of a real result or an error — easy to mistake for "no signal" instead of "broken tool."

Fix: both corrected. Neither bug ever touched real trading — one was a display/logging issue after the fact, the other only affected our own offline testing, never the bot's live decisions.

Checking why a stuck position wasn't closing led to something more fundamental: comparing what our own records said we held against the real exchange balance, two of the four positions in question had zero real coin behind them at all, and a third had over 99% less than our records claimed. No sell had failed or gone wrong — our own bookkeeping had simply drifted away from reality at some point and never been checked against the real account since.

This means the dollar exposure we were reporting for these was fiction, not a real live loss sitting there — the actual number was a few cents of leftover dust, not the roughly $58 our own tracking displayed.

Fix: corrected our records to match the real account balances, and — more importantly — built an automatic check that now compares our records against the real exchange balance every 15 minutes on every crypto bot, correcting or clearing anything that's drifted and alerting us the moment it happens, instead of this being found by accident again.

Our crypto bots each scan a rotating slice of the market rather than every coin at once, refreshed regularly to stay focused on where the real opportunity is. The safety checks that protect an open position — the trailing stop that locks in profit, the staged take-profit — were only ever run for coins currently in that scan list. A coin a bot was actually still holding, but which had since rotated out of its scan list (or gotten reassigned to a different bot's slice), stopped receiving either safety check entirely, with nothing anywhere flagging that this had happened.

Fix: a bot's own currently-held positions are now always included in its check, regardless of what's currently in scan rotation, so a real position never stops being protected just because the market scan moved on without it.

A routine review of our crude oil bot's take-profit and stop-loss settings found a wider first take-profit target and a tighter stop-loss both improved every real performance measure we track — total return, consistency, and the size of the worst drawdown — and the improvement held up in both the full history tested and the more recent half of it on its own, the same bar we hold every change like this to before trusting it.

Fix: updated live. No change to the bot's underlying strategy, only how wide its profit target and protective stop are set.

Our accounts trade in GBP, but every dollar figure on this site is meant to be a genuine USD conversion of the real result, not a raw currency mix-up. When a bot closes its own position (a normal take-profit or a stage of one), it correctly converts that result to USD before logging it. But when a broker-side stop-loss fires on its own — the safety net doing exactly its job — the code that records that close was pulling the broker's raw GBP number and logging it as if it were already in USD, with no conversion applied at all.

Since stop-loss closes are the larger, and mostly losing, side of the ledger, this consistently made real losses look about a quarter smaller than they actually were — enough, added up across months of trading on our gold bot alone, to turn a real loss into what looked like a small gain on this site.

Caught by checking our own numbers against the broker's real account history directly, the same way we catch everything here — real data, not the dashboard's word for it.

Fix: broker-side stop-loss closes now convert to USD the same way every other close already did, in all 9 affected bots. Every historical figure this affected was recalculated from the real broker record and corrected, not just fixed going forward — this site's whole point is an honest number, not a flattering one.

The scheduled job that renders every closed-trade card runs every 30 minutes, whether or not anyone's at the keyboard. Its Windows scheduled task is configured to run under an "interactive" login — which, it turns out, only works reliably while the screen is actually unlocked. Headless Chromium still needs real window-station access on Windows even in headless mode, so every run that happened to fire while the machine was locked failed to launch the browser at all.

Because a failed render is correctly left unmarked (see 2026-08-05 below), nothing was ever lost — but nothing forced a retry to actually succeed either. A handful of real trades, several of them on our oil bot, sat retrying every 30 minutes for days without a single successful attempt, and without anything surfacing that beyond a growing log file nobody was watching.

Fix: ran the pipeline by hand to clear the backlog — 14 real trades posted immediately, cards and clips both. Longer term: added a monitor that tracks how long any individual trade has been failing to render, and sends a real alert once it's been stuck long enough that "it'll clear on its own" is no longer a safe assumption, instead of waiting for someone to notice a gap in the feed. The underlying scheduling issue (switching the task off "interactive-only" login) is a real fix too, still pending.

Fixing an unrelated deployment issue meant briefly changing a domain setting on this site's host. That setting change made the host commit a change directly to this site's code — something our own automated publisher never expected another party to do.

From that point on, every scheduled update (new trade activity, market data, performance stats) tried to push its own changes and got silently rejected, because the two histories had diverged. Nothing crashed and nothing alerted — the script just logged a one-line failure and moved on, 48 times a day, for about two days. 26 real closed trades built up without ever getting a card or clip posted, and the site itself stopped updating.

Fix: recovered the 80 real updates that had been silently piling up locally and never reached the live site, then rendered and posted the 26 missing trade cards. More importantly: the publishing scripts now detect exactly this situation (a rejected push because the remote has changed) and automatically re-sync and retry once, instead of giving up. Tested against four scenarios — a clean push, a recoverable conflict, a genuine unresolvable conflict, and an unrelated failure — before shipping.

Hours after the previous fix below, the same "browser executable doesn't exist" error came back for three more trades, on a file that provably still existed on disk moments before and after each failure — no antivirus quarantine, no cleanup task, no environment mismatch between the automated run and an interactive one. That points to a brief race at the exact moment the browser process launches, not the file actually going missing.

Because of the previous fix, none of these five trades were lost this time — they sat correctly flagged as "not yet posted" until the pipeline could be run again by hand, rather than disappearing.

Fix: the browser launch now retries automatically (up to 3 attempts, spaced a couple of seconds apart) instead of failing on the first flake. The five delayed trades were posted immediately after.

The browser installation used to draw each card's image went missing a second time — same class of failure as 2026-08-04 below, a different underlying file this time. Any trade that closed during that window failed to render.

The real problem was what happened next: the trade's ID was recorded as "already posted" before the render was attempted, not after. So when the render failed, the trade stayed marked done anyway — no card, no retry, not on the next cycle, not ever, even once the browser was reinstalled. One of the four silently dropped this way was a real broker-side stop-loss close on Aurika.

Fix: reinstalled the browser, and reordered the pipeline so a trade is only marked posted after its card actually renders successfully. A failed attempt now retries automatically on the next run instead of vanishing. The four missed trades were identified and their cards posted after the fix.

The pipeline that renders every trade card and updates this site runs a headless browser to draw the image. At some point its browser installation went missing from disk. Every run after that crashed.

What made it worse: the crash handler's own error-printing line choked on a Unicode character inside the error message, on Windows' console encoding. That second failure happened inside the except block, which meant it wasn't caught — it killed the entire script, every single run, before it could reach any bot after the first failure, or update this site at all.

Fix: reinstalled the browser, and reconfigured the script's output to tolerate any character so a future bad error message can never again take the whole pipeline down — worst case now, one card fails and everything else still runs.

On 2026-07-15, a partial exit left 2 units logged as still open, with no matching close event ever recorded for them. The card-generation logic tracked a running position balance across the whole trade log, and once that balance stopped returning to zero, it never completed another trade — for any position opened afterward, for three straight weeks — even though the pipeline ran every 30 minutes without a single error.

Fix: every new position open now always starts a fresh lifecycle instead of assuming it might be continuing a prior one, which matches how these bots actually trade and makes the tracker self-healing against this exact class of gap.

The Binance API requires every signed request's timestamp to be within a tight window of the exchange's own clock. The trading library exposes a timestamp_offset for exactly this — and never sets it. Local clock drift measured as high as 6.7 seconds in a single session, non-monotonically, not a slow steady creep.

Fix: sync the offset against Binance's public time endpoint on startup, plus a background resync every 30 minutes for the long-running process.

Every dashboard's trade table picked the row label from whichever field happened to be set first — and the field that was actually set (the specific action: open, partial exit, cover, stop) came second in that check, behind a generic field that's the same for every row on one side of a trade. The result: a single position's real lifecycle rendered as what looked like duplicate entries.

Fix: reordered the field priority so the specific action is read first.

The function checking whether a position was still open had a final fallback: if both of its lookups failed for any reason — including a transient network blip — it returned 0 units. That return value was indistinguishable from "confirmed flat," so a genuine API hiccup got logged as a real broker-side close, complete with a fabricated result.

Caught by cross-checking logged closes against OANDA's real transaction history — several had no matching fill at all.

Fix: the fallback now re-raises instead of guessing, so a real lookup failure is treated as "skip this check," not "the position is flat."