Ansible deploy-stage timing
Each bar is a deployment run; colored segments show time spent in individual Ansible tasks.
Runs are oldest to latest, left to right. Only the 6 largest recurring tasks get their own color; everything else is grouped into a neutral "Other tasks" segment. The same task keeps the same color and the same stacking position in every bar, so a task that's grown slower (or newly appeared) is easy to spot. Hover a segment, or a legend entry below, to highlight that task across every run and fade the rest; the panel to the right then also shows how it compares to its own median and to the previous run. Click a segment (or a legend entry) to keep its highlight and details pinned while you look around; click it again, or click elsewhere, to release it. The dashed line marks the median total duration of the runs currently shown.
No deploy-stage data yet.
Galaxy startup timing
Each bar is a run; segments show time spent in each phase of Galaxy's startup sequence.
A different axis from the chart above: once the cluster is already up, how long Galaxy's own process takes before it starts serving requests. Bars line up with the same run positions shown in the deploy chart above - a blank column means that run's startup log wasn't captured. Hover or click a segment or legend entry for the same highlight-and-pin behavior as the deploy chart.
No Galaxy-startup timing data yet.
Job parallelism
How many Galaxy jobs ran concurrently throughout a run, split by where they executed.
Derived from each job's create_time/update_time in that run's raw tool-test results - an exact trace of every job start/end, not a fixed-interval sample, so a brief dip or spike is never smoothed away. Local k8s runner jobs share the same node as Galaxy itself and the cluster's control plane; GCP Batch jobs each get their own dedicated VM. Solid lines are jobs in flight (queued or running); dashed lines are the queued portion only - submitted but not yet actually executing, most visible for GCP Batch while its VM spins up. Dashed lines only cover jobs that ran to completion (Galaxy doesn't record a start time for ones that failed early), so their coverage is partial. Hover the chart for the exact counts at a point in time.
No parallelism data yet.
Job runtimes (GCP Batch)
One thin bar per GCP Batch job, positioned at when it actually started running.
Local k8s runner jobs aren't shown here - they're numerous and mostly short (see the parallelism chart above); this is about spotting which individual Batch jobs run long. Bars are ordered top-to-bottom by start time; sorting/filtering by tool or duration may be added later. Only jobs that ran to completion have the metrics this chart needs, so coverage is partial - typically around 60% of GCP Batch jobs in a run. Hover a row for the tool, version, runtime, and allocated cores/memory/container.
No GCP Batch job runtime data yet.