Pick an option on each card and press Done; your answer goes straight
back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.
1
In plain terms. Should I clear JPCO's AppFolio lockout now, or let it heal on its own by this morning? AppFolio itself is already back up fine — a login hiccup tripped a 6-hour automatic lockout on our side.
The full question, as raised
appfolio-browser-agent's per-identity login-failure breaker (lib/loginBudget.ts) escalated to its 6h tier for jpco's robot AppFolio login after 2 failures within 24h — the triggering one at 2026-10-15T09:50:02Z was LOGIN_UNEXPECTED_LANDING caused by AppFolio returning a 502 Bad Gateway on its own /users/oauth/login page, not a credential/MFA rejection. External curl just now shows jpco.appfolio.com answering 302 normally again. Clear now via POST /api/admin/login-breaker {identity: <jpco robot login email, APPFOLIO_JPCO_EMAIL>, action: clear}, or let the breaker expire naturally ~15:50Z?
Why, and what was tried
The session raising this recommends: Clear it now Both failures trace to LOGIN_UNEXPECTED_LANDING; this one's own log line says AppFolio served a 502 on its login page, not a bad password/MFA reject, and jpco.appfolio.com is confirmed healthy again by direct curl — nothing suggests the credential itself is bad. Tried first, unsuccessfully: Confirmed the cold session was real via prod Sentry + a read-only prod DynamoDB read of the watch state, then pulled live Vercel function logs for appfolio-browser-agent's cron/heartbeat and found the exact failure (502 on jpco's AppFolio login page escalating the login-failure breaker to 6h). Curled jpco.appfolio.com directly — healthy (302). Can't clear the breaker myself: the admin route needs jpco's exact robot login email, which isn't in my local checkout, and I won't guess at a security-lockout identity.