UI: Add cross-Dag Time Schedule view

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5

[minyeamer]

Add a Time Schedule tab for comparing Dag start times and durations across an Airflow environment.

Features:

• Day and Week timelines with overlap handling and fixed headers
• Mean, Max, and Min aggregation within zoom-dependent time buckets
• Pointer-anchored zoom using buttons, the mouse wheel, or arrow keys
• Existing Dag run, tag, timetable type, and optional team filters
• Configurable limits from the latest 200 runs through all matching runs
• Contiguous API pagination using the configured page size
• Gray expected-run bars for scheduled Dags without matching Dag runs
• Readable tooltips and links to the relevant Dag or Dag run
• Saved view, aggregation, run-limit, and scheduled-only preferences
• Light and dark theme support

This is a UI-only change. It reuses existing endpoints and adds no schema or backend API changes.

Earlier work in #68532 and #68547 informed the time-bucket design. The view placement follows #45497, while bounded loading follows the work in #47900, #60241, and #65388.

Related: #22001

---

Screenshots:

• Day view:

• Week view:

---

Videos:

• Zoom (Day view):

time_schedule-day-zoom_in_out.mp4

• Zoom (Week view):

time_schedule-week-zoom_in_out.mp4

• Dag run links (Day view):

time_schedule-day-bar_link.mp4

• Dag run limits (Week view):

time_schedule-week-display_n_dags.mp4

• Aggregation (Day view):

time_schedule-day-aggregation.mp4

---

Was generative AI tooling used to co-author this PR?

• Yes (GPT-5.6 Sol)

Generated-by: Codex (GPT-5.6 Sol) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Very cool! I could see a world where we could even show arrows between runs that are connected via partition keys. Or highlighting when Max active dag runs is being hit.

Love the minute detailing. That's great for dags that run every minute! Just needs a label.

1. Let's move this as a tab inside the Dashboard home page instead of in the tabled dags/runs/tis view.
2. Let's add the state icons to the bars so that they can be distinguished by something other than color
3. We need labels and/or tooltips to help explain some of these filters:
   a) Latest 200 should probably be "Limit" to be consistent with other views
   b) Mean/Max/Min means nothing to me without context
4. Day/Week modes are different types of views not a simple setting. It should probably match the tabs we have to change the calendar view on the dag details page.

5. The filters are a bit inconsistent. We have the Filter Pill UX that is used elsewhere but separately we also have timetable filters, scheduled dags only filter, and tag filters. Let's consolidate them all together. I also recommend rebasing since @ryanahamilton's recent changes add some great examples.

[bbovenzi]

This is a cool demo. But it definitely needs some work to "productionize" the code to be usable for deployments with any degree of scale.

[minyeamer]

@bbovenzi
Thanks for the detailed review. I interpreted the four main concerns as scalability and
data-flow issues rather than only UI adjustments.

Since b13f993, excluding merge commits, I made the following changes:

• Replaced client-side pagination and request fan-out with a dedicated streaming endpoint.
• Removed the unbounded "All Dag runs" option and enforced a maximum of 5,000 runs on the backend.
• Moved Dag and Dag run filtering into the backend query construction.
• Aggregate only the selected Day or Week view on the server.
• Stream results in batches so the UI can render progressively.
• Updated the filter implementation after the shared FilterBar changes were merged.
• Kept the private OpenAPI contract and generated client aligned with the backend route.

The current flow is:

flowchart TD
UI[Time Schedule UI] --> Hook[useTimeScheduleData]
Hook -->|One GET request| API[GET /ui/time-schedule]
API --> Filter[Apply authorization and filters in SQL]
Filter --> Limit[Select up to 5,000 Dag runs]
Limit --> Batch[Process 25 Dags per batch]
Batch --> Aggregate[Aggregate selected Day or Week view]
Aggregate --> Stream[Return NDJSON TimeScheduleBatch]
Stream --> Hook
Hook --> Render[Progressively render timeline bars]

Loading

The browser now receives only the filtered data needed for the selected view, while the backend controls the result size and aggregation cost.

I initially intended this change to remain UI-only and did not plan to add a backend API. Because the review identified the scalability limitations of the original approach, I needed to first understand Airflow's backend API structure, streaming session lifecycle, authorization filters, and OpenAPI generation flow. I also spent additional time reviewing the AI-assisted code carefully, which is why the follow-up changes took about 5 days.

The implementation is now focused on the production-scale concerns from the review while preserving the existing Airflow UI/API patterns.

[minyeamer]

I missed these additional suggestions in my previous follow-up. I plan to address the following:

• Move Time Schedule into the Dashboard as a tab.
• Add state icons to timeline bars so states are not distinguished by color alone.
• Improve labels and tooltips:
  • Rename Latest 200 to Limit 200.
  • Add context for the duration aggregation options.
• Replace the Day/Week selector with tabs.
• Consolidate the remaining filters through the shared Filter Pill UX.

For the partition-key arrows, I understand this may include dependencies between Dag runs, such as those created through TriggerDagRun. However, with the timeline sorted alphabetically by dag_id, the connections could easily cross and become difficult to follow.

I’m happy to implement this with more specific guidance on which relationships to show and how they should be laid out. With the current context, I’m hesitant to add a potentially confusing visualization.

---

Drafted-by: GPT-5