Description
In our downstream workflows, multiple jobs share the same dispatch timestamp (set when the workflow is triggered). The first job is usually a build, and later jobs wait for it to finish. Since all jobs report the same dispatch time, the calculated queue time (start – dispatch) for subsequent jobs incorrectly includes build/wait time, making the metric misleading.
Proposed solution
- Queue time – move to workflow level: compute it only for the first job (e.g., first job start – dispatch). This reflects true scheduling delay.
- Execution time – keep at job level: each job reports its own in-progress and completion times, so execution = completion – start.
This separates dependency waiting from actual queueing.
Open questions
- How to reliably identify the first job (e.g., by DAG roots or naming)?
- Should we keep a separate “wait for dependency” metric if needed?
Feel free to adjust any details as needed.
Description
In our downstream workflows, multiple jobs share the same dispatch timestamp (set when the workflow is triggered). The first job is usually a build, and later jobs wait for it to finish. Since all jobs report the same dispatch time, the calculated queue time (start – dispatch) for subsequent jobs incorrectly includes build/wait time, making the metric misleading.
Proposed solution
This separates dependency waiting from actual queueing.
Open questions
Feel free to adjust any details as needed.