browser automation failed when agent tried to open the airflow UI

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 UI

Use 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

1. Confirm what the agent actually needed from the UI: run state, logs, config. Note the need. Verify: the requirement is explicit
2. Map the need to REST API endpoints: dag runs, task instances, logs. Note the mapping. Verify: the API covers it
3. Retry via the API with proper auth. Note the successful read. Verify: the data arrives without a browser
4. Reserve browser automation for truly visual needs: layout checks, rendered graphs. Note the policy. Verify: the browser is the exception, not the rule
5. 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

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

Thread query: browser automation failed when agent tried to open the airflow UI

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.