The Airflow UI
What the UI shows you
The Airflow web UI is the fastest way to answer operational questions: is a DAG paused, when did it last run, why did a task fail, and what is its log? The DAGs view lists every DAG the scheduler has parsed, with toggles for pause state and links to trigger a run manually. The Grid view is the default DAG detail page: columns are DAG runs, rows are tasks, and colored squares encode task states such as success, running, failed, upstream_failed, skipped, and queued. Clicking a square opens the task instance with its logs, rendered template fields, XCom values, and a Clear action that resets state so the scheduler can re-run it.
Other views matter too. Graph shows the dependency structure; Calendar and Gantt show timing; Code shows the parsed DAG source; Browse exposes DAG runs, task instances, variables, and connections; Admin holds connections, variables, and pools. The Runs view lists run types (manual, scheduled, backfill, dataset) and their states.
Traps to watch
A common trap is confusing pausing a DAG with stopping running tasks: pausing prevents new scheduled runs but does not kill tasks already running. Another is assuming the UI edits DAG code: the Code view is read-only, and edits must happen in the DAG file. Also remember the UI reads from the metadata database, so what you see reflects scheduler-parsed state, not the file on disk at this instant. Clearing a task does not delete history; it creates new task instance attempts.
Rule of thumb
When a question asks "where do I confirm X," map it: state and logs → Grid/task instance; dependencies → Graph; configuration values → Admin/Browse; source → Code.