## TL;DR
Browser automation against portals breaks for portal reasons, not patch reasons: redesigned pages move the elements, sessions expire mid-watch, and interstitials (consent, MFA, maintenance banners) insert steps the script never expected. Prefer the portal API or an RSS or status feed wherever one exists; where the browser is unavoidable, make the automation defensive: identify elements by stable attributes, detect and log interstitials explicitly, refresh sessions on a schedule, and screenshot on failure so the breakage is diagnosable.

```text
agent's browser automation failed monitoring the update portal install
```

## Use this when
- The portal watcher reports nonsense states or times out finding elements after a portal update.
- The automation works in the morning and fails after a session lifetime expires.
- Failure screenshots show a consent, MFA, or maintenance page the script did not handle.

## Not for this skill when
- The portal offers an official API or status feed. Migrate to it; browser fixes are wasted effort.
- The portal is down for everyone. That is a vendor outage to wait out, not an automation bug.

## Steps
1. Capture the failure state: save a screenshot and page source at the failure point for the last breakage. Verify: you can see which breakage class (layout, session, interstitial) occurred
2. Check for an API, feed, or email alert alternative for the same data and switch if one exists. Verify: the alternative delivers the same fields the wave consumes
3. If the browser must stay, re-anchor selectors to stable attributes (form names, aria labels, data attributes) rather than positions or styling classes. Verify: the script survives cosmetic page changes in a test
4. Add explicit handling and logging for session expiry and interstitial pages: detect, re-authenticate if allowed, or stop with a named reason. Verify: an expired-session test ends with a clear session-expired state, not a timeout
5. Add a watcher health check that alerts when the automation itself fails, separate from patch alerts. Verify: a deliberately broken selector pages the automation owner, not the patch channel

## Variant phrasings
### browser automation portal layout changed selectors break
The layout phrasing.
### portal session expired automation mid run reauthenticate
The session phrasing.
### use api instead of scraping patch portal monitoring
The structural-fix phrasing.

Compatibility: Compatibility: Any browser automation stack (Playwright, Selenium, Puppeteer); portal terms of use may restrict automation and are the operator responsibility.

## Why it happens
Portals are designed for humans and change without notice, so automation against them carries a standing maintenance cost that APIs do not. The failures are also misleading: a watcher that cannot find its element may report the update as missing, converting a UI change into a phantom patch problem. Treating the watcher as a system that itself needs monitoring and failure evidence (screenshots, page source) is what separates a nuisance from a data-integrity risk.

## Edge cases / pitfalls
- Never let portal readings be the sole source for a patch decision; cross-check with host-reported state before acting.
- Credential and MFA handling for portals must follow the same vault and service-account rules as any other agent auth; a script with a human personal login is a finding.
- Portal maintenance windows are predictable; teach the watcher the vendor status page so it can label those hours correctly.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0AtPrcPbT3qxEF4ao6F6EQ