Skip to content

Show exact dag run and task instance counts on the dashboard - #70892

Open
jedcunningham wants to merge 1 commit into
apache:mainfrom
astronomer:dashboard-exact-counts
Open

Show exact dag run and task instance counts on the dashboard#70892
jedcunningham wants to merge 1 commit into
apache:mainfrom
astronomer:dashboard-exact-counts

Conversation

@jedcunningham

Copy link
Copy Markdown
Member

The dashboard counted each state separately with a limit of 1000, so any busy state showed "1000+" instead of a real number. On a large install almost every state sat at the cap, leaving the panel with no usable figures at all.

Count the window in a single scan instead. When it fits, every count is exact. When it does not, report what was read as a lower bound, rounded down, which stays closer to the real volume than a fixed cap. Dag runs and task instances are judged separately, since a window often holds few enough dag runs to count exactly while holding far too many task instances.

Counting a bounded number of rows is also cheaper than the old per-state limits, which scanned the whole window for any state that could not fill its own limit (postgres, 12M task instances):

window before after
15min 15 ms 4 ms
24h 3,270 ms 45 ms
7d 20,752 ms 46 ms

MySQL and SQLite behave the same way.

The Dags list keeps its previous capped counts and now owns that constant.

Exercised against a running Airflow holding 140k dag runs / 420k task instances.

A 12-hour window reports both groups exactly:
Screenshot 2026-07-31 at 2 41 23 PM

A 24-hour window reports exact dag runs beside bounded task instances:
Screenshot 2026-07-31 at 2 41 33 PM

And a 7-day window bounds both:
Screenshot 2026-07-31 at 2 41 41 PM

Percentages are hidden and the bar fills whenever a group is bounded, since the proportion is unknown.


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

The dashboard counted each state separately with a limit of 1000, so any busy state
showed "1000+" instead of a real number. On a large install almost every state sat at
the cap, leaving the panel with no usable figures at all.

Count the window in a single scan instead. When it fits, every count is exact. When it
does not, report what was read as a lower bound, rounded down, which stays far closer
to the real volume than a fixed cap. Dag runs and task instances are judged separately,
since a window often holds few enough dag runs to count exactly while holding far too
many task instances.

Counting a bounded number of rows is also cheaper than the old per-state limits, which
scanned the whole window for any state that could not fill its own limit (postgres, 12M
task instances):

  window   before      after
  15min       15 ms      4 ms
  24h      3,270 ms     45 ms
  7d      20,752 ms     46 ms

MySQL and SQLite show the same pattern.

The Dags list keeps its previous capped counts and now owns that constant.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant