browser automation failed when agent tried to open the airflow UI
Gives agents a fallback plan when browser automation cannot open the Airflow UI: the API-first approach and when the UI is actually needed. Use when automated browser access to Airflow fails. Not for API access problems.
TL;DR
The browser automation failed on login, SSO, or a slow page load, but the agent probably did not need the browser: the Airflow REST API covers runs, task states, and logs. Fall back to the API first and reserve the browser for genuinely visual checks. An agent that needs a browser for routine Airflow reads is using the wrong tool.
browser automation failed when agent tried to open the airflow UIUse this when
- Browser automation fails opening the Airflow UI.
- SSO or login blocks the automated browser.
- The agent only needs run or task data, not visuals.
Not for this skill when
- The REST API is also unreachable. That is a connectivity problem.
- A human needs the UI. This is about agent access.
Steps
- Confirm what the agent actually needed from the UI: run state, logs, config. Note the need. Verify: the requirement is explicit
- Map the need to REST API endpoints: dag runs, task instances, logs. Note the mapping. Verify: the API covers it
- Retry via the API with proper auth. Note the successful read. Verify: the data arrives without a browser
- Reserve browser automation for truly visual needs: layout checks, rendered graphs. Note the policy. Verify: the browser is the exception, not the rule
- If the UI itself is broken for humans too, report it as an Airflow problem. Note the report. Verify: a real UI outage is distinguished
Variant phrasings
airflow api instead of ui
The API-first phrasing.
browser automation airflow sso blocked
The auth-shaped search.
Compatibility: Airflow 2.x REST API and web UI. Browser automation tools vary; the fallback pattern does not.
Why it happens
The Airflow UI is a human interface with human authentication: SSO flows, session cookies, JavaScript-heavy pages. Automated browsers fight all of that, flakily. The REST API is the machine interface: token auth, structured responses, no rendering. Agents that default to the browser are imitating humans instead of using the interface built for them. The browser failure is often a gift: it forces the switch to the API, which is faster and more reliable anyway.
Edge cases / pitfalls
- RBAC can give the API different permissions than the UI session. Verify the API credential can read what the agent needs.
- Some Airflow views have no API equivalent (the rendered graph). For those, the browser is genuinely required.
- An API that hangs is not better than a browser that fails. Bound API calls with timeouts too.
- SSO-blocked browsers sometimes indicate expired human credentials, not an automation bug. Check before rebuilding the automation.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstfzKRnKDrSfiA8EJicXWYw