Show larger dag run and task instance counts on the dashboard by jedcunningham · Pull Request #70892 · apache/airflow

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham · 2026-08-01T03:05:56Z

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:

A 24-hour window reports exact dag runs beside bounded task instances:

And a 7-day window bounds both:

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.

github-actions · 2026-08-03T17:08:56Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…oard (apache#70892) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…oard (#70892) (#71008) 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. (cherry picked from commit b316afb) Co-authored-by: Jed Cunningham <66968678+jedcunningham@users.noreply.github.com>

…#70892) 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.

jedcunningham requested review from bbovenzi, bugraoz93, choo121600, ephraimbuddy, guan404ming, henry3260, jason810496, pierrejeambrun, rawwar, ryanahamilton, shubhamraj-git and vatsrahul1001 as code owners August 1, 2026 03:05

boring-cyborgBot added area:API Airflow's REST/HTTP API area:UI Related to UI/UX. For Frontend Developers. labels Aug 1, 2026

jedcunningham force-pushed the dashboard-exact-counts branch from b9942f9 to 696162aCompare August 3, 2026 13:53

jedcunningham changed the title ~~Show exact dag run and task instance counts on the dashboard~~Show larger dag run and task instance counts on the dashboardAug 3, 2026

bbovenzi approved these changes Aug 3, 2026
View reviewed changes

bbovenzi added the backport-to-v3-3-test Backport to v3-3-test label Aug 3, 2026

bbovenzi added this to the Airflow 3.3.2 milestone Aug 3, 2026

bbovenzi merged commit b316afb into apache:mainAug 3, 2026
99 checks passed

bbovenzi deleted the dashboard-exact-counts branch August 3, 2026 17:07

vatsrahul1001 modified the milestones: Airflow 3.3.2, Airflow 3.3.1 Aug 4, 2026

bbovenzi mentioned this pull request Aug 6, 2026
Restore count to Dag Run and Task Instance lists #71252
Merged
1 task