在我们的开发环境中，我们有大量的存储库、大量的构建和大量的构建服务器，并且大多数时候事情都按应有的方式工作 - 但是，我们看到由于超时而失败的构建有所增加。
这些超时不会发生，因为我们正在接近极限，而是因为管道中“卡住/阻塞”了某些东西，并且它一直停留在该步骤，直到超时终止构建。
为了更好地调试为什么会发生这种情况，我们需要能够查询由于此超时而导致构建失败的原因，因此我们可以查看是否是特定的构建服务器或代理存在此问题。
我们在 API 中找不到任何会给我们带来超时错误的东西，但我们可以看到 UI 能够以某种方式扣除它：
到目前为止，我们已经将范围缩小到查询所有具有已完成状态的构建（通过此 API），但我们没有完成原因，并且构建时间与构建定义的超时时间永远不会完全相同，因此从执行中“猜测”它计划也会有点不稳定。
我们如何才能将构建过滤到仅已超时的构建？
我们可以使用下面的API来获取构建的详细信息。
注意：不要添加timelineId，我们应该列出所有信息
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/timeline?api-version=6.1-preview.2
如果由于超时设置而取消构建，我们可以得到消息：The job running on agent Hosted Agent ran longer than the maximum time of xxx minutes. For more information, see https://go.microsoft.com/fwlink/?linkid=2077134
顺便说一句，我们可以使用 API Builds - List来过滤所有失败的构建。如果由于超时设置而取消构建。结果是失败而不是取消。