I Trusted a Cookie Audit. It Cost Me 50 Hours of Cron Runs.

I run a small growth bot. Every four hours it tries to warm up seven platforms: log in, leave a couple of upvotes, write one useful comment, log out, repeat. The cron was ticking. The engagement log had rows. The KPI counter said zero.

For two days.

Here is what I missed.

The audit that lied

On a Tuesday I did a manual login sweep. Google Docs cookie export, check the cookie names against each platform's session format, mark every platform logged_in: true if the cookie name pattern matched. Eight of nine platforms got a green check. The cron picked up the green checks and ran happily for fifty hours.

Forty-eight hours later I opened the engagement log and noticed the pattern. Every row was a warmup_skip_no_recent_run or a comment_attempt_failed. No verified actions. Not a single one.

I checked the cookie table again. Same eight green checks. Same session cookie names.

Then I opened the browser tab for the first platform, Reddit, and saw this:

"This account has been banned."
Log In · Sign Up

The cookie name was right. The cookie value was empty. The cookie database entry was stale.

What "logged in" actually means

A cookie audit tells you whether the shape of a session is present. It does not tell you whether the session is alive. A session dies when the platform revokes it, when the IP changes, when the user clears cookies, when the user is banned. The cookie name pattern stays in the table. The cookie value goes blank. The audit keeps reporting logged_in: true.

I had been running a warmup cron against dead sessions for two days. The selector picked Reddit, looked for reddit_session in the cookie jar, saw the name pattern, and proceeded to upvote. The upvote click resolved to a Log In wall. The click silently failed. The cron logged "warmup complete" and moved on.

The first fix that did not work

I tried to add a post-action verification step. After every warmup action, fetch the user profile, count the karma, compare to before. If karma did not go up, mark the row as verified: false.

This helped on the way down. It did not stop the burn on the way up. The cron still ran. It still ticked. It still used tokens. It just produced honest-looking-but-zero KPI.

The fix that did work

I moved the check to the front. Before the selector picks a platform, before the skill is loaded, before any browser work, probe the session.

For Reddit, the probe is one runtime check against https://old.reddit.com/user/<handle>/. Read the document title. If it contains "banned", mark the platform dead. If the page redirects to /login, mark it dead. If neither, the session is alive.

If the probe fails, write a 24-hour cooldown entry. Append one log row with action: skipped_no_login. Stop the cron for this hour. No skill loads. No browser work happens. No token burn.

If the probe passes, run the selector as before.

The number I am willing to defend

Eight platforms. Fifty hours. Zero verified actions. One stale cookie audit.

After the guard went in: 11 verified comments in 36 hours. One Reddit account re-recovered. Two platform cooldowns cleared after manual re-login. The KPI counter started moving.

The lesson is not "add a probe step." The lesson is that an audit you do once and trust forever is worse than no audit at all, because it makes you stop looking.

I built AI Buddy, a small Chrome side panel that ships prompts to ChatGPT, Claude, Gemini, DeepSeek, WhatsApp Web, Telegram, and Discord from one keystroke. The growth loop that warms it up taught me more about session management than the side panel itself did. 18 users, two of them replied to a thread I started about this exact bug.