The Airflow UI
The Airflow webserver serves a Flask-based UI that is your primary window into what's running, what succeeded, and what failed. The landing page is the DAGs list, showing every DAG discovered in your DAGS_FOLDER along with its schedule, owner, last run status, and a toggle to pause or unpause it — a paused DAG is parsed but never scheduled. From there, clicking into any DAG opens detail views (Grid, Graph, Calendar, Code, and more) that let you drill from a bird's-eye view of every run down to a single task's logs.
Cricket analogy: The DAGs list view is like a cricket league's fixtures page showing every scheduled match, its venue, and its current status — you click into a specific fixture to get ball-by-ball detail.
The DAGs View and Grid View
The Grid view (which replaced the old Tree view in Airflow 2.x) shows a matrix of DAG runs as columns and tasks as rows, with each cell colored by state — dark green for success, red for failed, orange for up_for_retry, light blue for running. This is usually the first place you check when investigating a problem, because you can immediately spot patterns like 'every run has failed since Tuesday' or 'only this one task keeps retrying', and clicking any cell opens a details panel with logs, XCom values, and manual actions like Clear or Mark Success.
Cricket analogy: The Grid view is like a Test series scorecard grid showing each day's session results across five matches — a quick scan reveals a batting collapse pattern on day three of every game.
Graph View and Task Instance Details
The Graph view renders the DAG's actual dependency structure as nodes and edges, which is the best place to understand a DAG's logical shape — especially useful for DAGs with branching (BranchPythonOperator) or fan-out/fan-in patterns using Dynamic Task Mapping, since the Grid view flattens dynamically mapped tasks into a single row while the Graph view can expand them. Clicking a task node opens the Task Instance details panel showing its start/end time, duration, the exact rendered template (for Jinja-templated fields), and buttons to view logs or manually clear/retry that instance.
Cricket analogy: The Graph view is like a fielding placement diagram showing exactly where each fielder stands relative to the bowler and batter — you see the spatial relationships, not just a list of names.
# Launch just the webserver for local inspection (SequentialExecutor/standalone setups)
airflow webserver --port 8080
# Or, for a full local dev environment in one command:
airflow standalone
# Prints the generated admin username/password to the terminal on first runClicking 'Mark Success' on a failed task instance does not re-run the task — it simply tells Airflow to treat it as succeeded so downstream tasks can proceed. Use it only when you've manually verified the underlying work actually completed; otherwise use 'Clear' to force a genuine re-run.
Logs, Trigger DAG, and Variables/Connections UI
Every task instance's logs are viewable directly in the UI, streamed live while a task is running and stored afterward (locally, or in remote storage like S3 if remote_logging is configured). The 'Trigger DAG' button lets you kick off an ad hoc run outside the normal schedule, optionally with a custom JSON config passed to dag_run.conf. Under Admin, the Connections and Variables screens let you manage credentials and shared config values used by your tasks without hardcoding them into DAG files — Connections store things like database URIs and API keys (with sensitive fields masked), while Variables store arbitrary key-value config.
Cricket analogy: Task logs streaming live are like ball-by-ball radio commentary during play, while the Connections screen is like a team's confidential contact book of physios and specialists that isn't printed in the public program.
- The DAGs list is the landing page, showing every discovered DAG with its schedule, owner, and pause toggle.
- The Grid view (successor to Tree view) shows DAG runs as columns and tasks as rows, color-coded by state.
- The Graph view renders the actual dependency structure, best for understanding branching and dynamically mapped tasks.
- Task instance details include start/end time, duration, rendered templates, logs, and manual retry/clear actions.
- 'Mark Success' does not re-run a task — it only marks it succeeded; use 'Clear' to force a real re-run.
- The Trigger DAG button starts an ad hoc run, optionally passing a JSON config via dag_run.conf.
- Admin > Connections and Variables store credentials and shared config outside of DAG source code.
Practice what you learned
1. What view replaced the old Tree view in Airflow 2.x for showing DAG run history?
2. Which UI view is best for understanding a DAG's branching structure created with BranchPythonOperator?
3. What does clicking 'Mark Success' on a failed task instance actually do?
4. Where in the Airflow UI would you store a database connection string used by multiple DAGs?
5. What happens to a DAG when it is 'paused' in the DAGs list view?
Was this page helpful?
You May Also Like
The Airflow Architecture
How Airflow's scheduler, webserver, executor, and metadata database work together to parse, schedule, and execute your DAGs.
Your First DAG
A hands-on walkthrough of writing, testing, and triggering your first Apache Airflow DAG, covering DAG anatomy and task dependencies.
Installing Airflow
A practical walkthrough of the main ways to install Apache Airflow, from a local pip install to Docker Compose, and how to verify the install worked.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics