The scary part of running an automation fleet isn't the error you see — it's the one that never throws. My accounts didn't crash when they failed. They quietly poisoned themselves, and I only noticed days later when the ban wave landed.
Over the last month I scaled from one headless browser to 40 concurrent accounts. Along the way I found that the three costliest bugs produced no stack trace at all. Here they are, in the order they bit me.
1. reCAPTCHA v3 fails without a checkbox
There is no "I am not a robot" to click. The score just decays silently on every request, and by the time a form rejects you, the account is already flagged. I logged token scores for a week to prove it: clean manual flows sat around 0.9, my automated ones averaged 0.3 — and the worst part is the requests still returned 200 the whole time.
The fix wasn't a solver. It was treating every action like a gesture: slower typing, real pauses, and keeping one session inside one geographic identity for its whole lifetime. The score crawled back up to 0.7 without touching the captcha code.
2. The confirm-by-link flow broke accounts that looked fine
Signup forms were solved long ago. The step that silently killed 6 accounts was email confirmation: I clicked the confirmation link in the wrong browser context, and the platform bound the confirmation to the wrong session. No error, no warning — the account just stayed unverified forever, and every post after that hit a wall I couldn't see.
The rule that stopped it: one context per email, and confirm inside the same session that submitted the form. Boring, but it removed an entire failure class.
3. I had no idea which accounts were actually healthy
After the first ban wave I realized I couldn't answer the simplest question: which of my 40 accounts still worked? I had logs of commands, but nothing tying an account to its IP, its fingerprint, and its last real outcome.
The single most useful thing I built was a 20-line audit log — one row per run: account, platform, IP, fingerprint hash, outcome. When the next wave hit, I diffed locked vs. alive in five minutes instead of guessing for a day. The log didn't make anything faster; it made everything visible.
4. Warm-up that isn't measured isn't warm-up
I "warmed up" accounts by waiting 24 hours and called it done. Then I looked at the data and found the accounts I'd actually used during warm-up — one real read, one profile edit — survived at twice the rate of the ones that just sat idle. Passive waiting did almost nothing; light real activity did the work.
5. Two accounts, one platform, same text = a repeat, not scale
I caught myself cross-posting near-identical text to two accounts on the same site. It wasn't banned, it was just noise — and the moment anyone compared the feeds it would have been an obvious duplicate. Same platform needs a different angle, or it doesn't need to happen.
The lesson I'd compress it all into: the bugs that kill an automation fleet are the ones that never throw an error. If you can't tell which accounts are healthy at a glance, you're running blind no matter how many proxies you have.
If you're scaling your own fleet, build the audit log before you build the automation. Visibility first, proxies later — that order would have saved me a full week.
Top comments (0)