Exit 0 only means nothing threw: what a logged-out browser costs a cron job

A scheduled browser-automation lane ran twelve times a day, logged "complete" on every run, sent no errors to its monitoring dashboard, and produced zero likes and zero follows for days ^[1][2]. The account it drove, `ig-2`, had been logged out and its Instagram session had expired; the job, parked on a logout screen, kept returning exit 0 on the reasoning that there were no targets left or no accounts matched the criteria ^[3][4].

The developer, writing on dev.to, says the lane looked normal until the morning of 2026-08-09 ^[5]. There was login-detection code. `needLogin()` in `social-autolike/src/run.js` flagged a login as required if the URL contained `/login`, or if the body contained the Japanese word for login and none of `article`, `[role=feed]`, `video`, `main` or `[data-e2e]` were present ^[6]. Instagram's logout screen contains a `main` element, so the second condition never fired: one `main` was found, and the check passed the logged-out page as healthy ^[7].

That is the whole failure in miniature. A selector answers "does this page look like a login screen," which is not the question; the question is whether this browser is currently authenticated, and the first proxy dies the moment the markup changes ^[8].

The replacement assertion reads state instead of appearance. Chrome keeps session cookies in a SQLite file at `Default/Network/Cookies`, or `Default/Cookies` on older versions ^[9]. Instagram's login state lives in a cookie named `sessionid`; if that cookie exists for the `instagram.com` domain, the profile is logged in ^[10]. The author's argument for making cookies the primary source is that the mapping holds regardless of redesigns to the logout page ^[11]. Anything driving a Chrome or Chromium profile is exposed to the same gap, whether the driver is Playwright, Puppeteer, browser-use, or something assembled with Claude Code ^[12].

The guard script, `profile-session-guard.sh`, runs before the work and stops the lane with a notification when the session is dead ^[15]. Four stages: resolve the profile directory list from three config files (`accounts.json`, `ig-reply-accounts.json`, `post-accounts.json`) plus two fixed entries from a separate repo, collapsing duplicates ^[16]; look for the cookie DB at `Default/Network/Cookies`, `Default/Cookies`, `Network/Cookies` or `Cookies`, and copy it with `mktemp`, deleting the copy on exit ^[17]; query the copy with `sqlite3` using a per-platform SQL statement and grade each profile OK, EXPIRED or UNKNOWN ^[18]; then aggregate, compare against a state file, skip the notification when the breakage matches the previous run, and on a new breakage send a Discord message and exit 1 ^[19].

The cost of not doing this is measured in silence. A graph pinned at zero is hard to notice while no errors fire, and the author could not reconstruct how many days `ig-2` had lost ^[13][14]. At twelve runs a day, a single week of that is eighty-four consecutive green runs ^[20].

Two things to watch if you copy the pattern. UNKNOWN is a real third outcome in this design, not a rounding error, and it needs a policy: treat it as expired and you halt on a moved database file, treat it as fine and you are back to guessing ^[18][9]. And the state-file deduplication that stops Discord from repeating itself also means a lane that stays broken tells you once ^[19], so the durable check is the inverse of the one that failed here: alert on a lane that has produced nothing while claiming success, not on a lane that threw.