Since it was posted 7 years ago the underlying APIs at Buildkite now have this information (see post) but it would be much better if every customer didn’t have to do this and the metrics collector just provided it directly.
It’s also an awkward patch to propose to buildkite-agent-metrics because the service has a nice clean signal token and API endpoint which does not have this information, so it would need to learn to talk to another API, I think this is best done internally by buildkite.
Thanks for reaching out here and for re-raising this issue on the buildkite-agent-metrics. Good news is we’ve already assessed the work required to support this. However, it is still in the backlog and could not commit on a delivery timeline. However, I can report. back to our engineering team on your interest. You will reply back here - Feature request: Wait time of the oldest scheduled job as a metric · Issue #92 · buildkite/buildkite-agent-metrics · GitHub - when we have updates on this work.
Lizette thanks for the quick response, I look forward to an update from engineering on the issue.
This might seem minor but it’s actually really high impact work. It provides a clear signal that helps teams catch bad build cluster situations early and fix them before large impact to their company. This work prevents each customer building this themselves, probably after a few painful incidents, and this assumes they actually know they need this.
With AI/LLM use surging investing in features that let your customers handle extreme load CI is a key competitive advantage over competitors like GitHub Actions and their very poor reliability.
Hi @jlisee-glydways thanks for the additional context here, I will follow up on the assessment with these points for further review as I also understand your points here
