## TL;DR
Logins are the flakiest part of browser automation. Isolate the login into its own step with explicit waits and retries, reuse SSO sessions where allowed, and only proceed to the billing data once login is verified.

```text
agent's browser automation failed on SaaS admin billing page login
```

## Use this when
- Browser automation fails at the login step of a billing portal.
- The failure is intermittent.
- Later steps would work if login succeeded.

## Not for this skill when
- The portal blocks automation. Use the sanctioned API or export.
- Login succeeds but the data page fails. That is a page problem.
- The credential itself is wrong. Fix the credential.

## Steps
1. Separate the login from the data-collection steps. Verify: login is its own step.
2. Add explicit waits for each login field and the post-login landing element. Verify: waits target elements, not sleeps.
3. Retry the login up to three times with fresh sessions. Verify: retries are clean attempts.
4. Reuse SSO sessions across runs where the policy allows. Verify: the session is valid.
5. Verify login success before proceeding to billing data. Verify: the gate holds.

## Variant phrasings
### browser login failed
The short phrasing.
### automation login timeout
The symptom-first search.
### billing page login
The page-first phrasing.

Compatibility: Any browser automation driving SaaS logins.

## Why it happens
Login pages involve redirects, MFA, and bot checks. Treating login as one atomic step hides which part failed; isolating it makes each failure diagnosable.

## Edge cases / pitfalls
- MFA prompts the agent cannot pass; use a session with MFA already completed per policy.
- Password managers interfering with field fills; disable them in the automation profile.
- The landing element changing on redesign; wait on something stable.
- Three retries being too few on very flaky portals; tune, but cap.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MtjR-Ha7g7ZIq49Kl3PDgQ