Queue backlog Master and pull request jobs ready to run but with no agent yet, per pool (queue, OS and architecture), kept for 60 days. Per slot divides by the slots seen in the last 30 days; the tooltip names pools that share their hosts' slots.
Machine balance Pools whose agents run on the same machines, with each pool's jobs running and waiting as a multiple of its slots. Above 1× a pool has a queue; below it has idle slots.
Connected agents Agents connected at each update, all queues. The build, test, launch and default queues start one agent per job, so they are listed per host and a host is flagged after 3 days without a job. Other agents are flagged when missing from the latest snapshot.
Loading agent snapshots...
Jobs per host Per day, master builds only, so an empty cell is not downtime.
Loading worker history...
The share of agent time taken by each kind of job, from the master (julia-ci) and pull request (julia-pr) jobs that finished in the last 7 days, each counted from start to finish. Jobs still running are left out.
Each point is one master build: its wall time from the first job starting to the last finishing, the median wait of its jobs between becoming runnable and starting on an agent (the queue), and the total job time it consumed. Builds fetched from the Buildkite API since the database started carry the timestamps; click a point or row to open the build. Builds still running are faded: their job time and queue wait are partial.