BAS Errors: Why Your Bot Fails and How to Debug It

A BAS bot almost never breaks “on its own”. It breaks where reality diverged from expectation: the page arrived slower, the markup changed, the proxy died. Debugging is mostly the skill of finding out quickly where that happened.

Element not found

The most common error, and the most commonly misdiagnosed. There are exactly three causes, and they need different fixes.

The element is not there yet. The script reached the check before the page finished rendering - normal for anything loaded dynamically. The fix is not a longer pause but waiting on the element itself: a fixed pause either wastes time or turns out to be too short one day.

The selector is brittle. It is pinned to a class like css-1x7f9a generated by a bundler, and that class changes on every deploy. Anchor to things that carry meaning instead: text, attributes, structure. More in the guide to selectors that do not break.

The element is in another context. It sits inside an iframe or another tab while the bot searches the current document. It is on screen, but as far as the script is concerned it does not exist.

The browser will not start

When a thread dies immediately at launch, check in this order:

1. Memory. The usual cause is more threads than the machine can hold - the browser cannot start because there is no RAM left. Lower the thread count and see whether the error disappears.
2. First run after compiling. A compiled bot needs to download its environment, and without internet it will not start.
3. Antivirus. An automation app that fetches components is a textbook blocking candidate.
4. Leftovers from earlier runs. Orphaned browser processes from crashed threads hold memory and get in the way of new ones.

Proxy not responding

Proxy errors are treacherous because they wear other errors’ clothing. The bot reports “page did not load” or “element not found” when the real cause is a dead address.

The tell: failures are tied to a thread, not to a step. If thread 4 always dies while the others run fine, its proxy is almost certainly the reason. Which argues for testing proxies before the run rather than inferring their health from crooked symptoms mid-scenario.

The script hangs

A hang differs from a crash: the bot reports nothing, it simply stands still. The cause is always the same - waiting on an event that will not arrive:

• waiting for an element that will not appear on this page;
• waiting for a load that finished before the wait started;
• waiting for an email code that is never sent.

The fix is structural: every wait needs a finite timeout. A bot that fails in a minute with a clear message is incomparably better than one that ties up a thread for a day and poisons your statistics.

Works in the studio, fails in production

A classic with three sources. First, speed: in the studio you watch the bot and unconsciously give it time, while at ten threads pages load slower. Second, paths: relative and absolute diverge after compiling. Third, state: in the studio you run against an already logged-in profile, while production starts from zero.

The test is simple: run on a clean profile at full thread count. Most “inexplicable” divergences surface immediately.

A debugging setup

Debug from evidence, not from guesses. The minimum kit, which pays for itself on the first incident:

Log steps, not the fact of failure. A line saying “error” is useless. A line saying “thread 4, account ivan@mail, step Login, submit button not found” is nearly a diagnosis. Write to a file through the tools module, not just to the screen - you will not be watching the screen when the bot runs at a client site.

Screenshot on failure. One image answers in a second what otherwise costs an hour: whether there was a captcha, a redirect, a consent banner or a blank page. It is the cheapest diagnostic tool in automation.

Save the HTML on failed steps. When a selector stops matching, the only way to understand why is to see the markup that was actually there.

Count failures by type. Separate “element not found” from “proxy died” from “captcha” - different problems with different fixes. An aggregate “40% failure rate” tells you nothing; statistics broken down by cause tell you what to repair.

Retries instead of crashes

Some errors do not warrant stopping - they are transient: the network blinked, a page came slower than usual, a proxy hesitated. Those steps deserve a retry rather than taking down the whole thread.

The dividing rule is simple. Retry network failures and load timeouts - things that may well pass on the next attempt. Do not retry wrong credentials, a missing account, or an exhausted quota: retrying there only burns time and brings a ban closer.

And separately: a retry without a limit is a hidden infinite loop. Always cap the number of attempts.