Performance

The Performance page, under Analytics, shows how long your workflows and jobs usually take over the past 24 hours, 7, 14 or 30 days. Times come from successful runs only, since a failed run stops early. The ⓘ beside each column explains how it’s worked out.

Workflows

For each workflow: its runs, the share that succeeded, and the median and p90 time from a run’s start to its last job finishing. That time includes any wait for a runner, so it’s what you actually wait for. Waiting is how much of that time no job was running, mostly jobs waiting for a runner.

Trend compares the range with the one just before it, such as the past 7 days with the 7 days before; red means the workflow got slower. The 30-day range has no trend, since job history goes back 31 days. Slowest job is the job that usually takes longest. Open it to compare its times on each runner.

Jobs

How long each job usually takes on each runner it ran on, fastest first. Use it to see which runner suits which job: a test suite that takes 2 minutes on your Mac and 9 on ubuntu-latest is a good one to route. A time from fewer than 20 runs reads “only 7 runs”: hover it to see how much to trust it. Open a job for a chart of every run.

Runners

Each runner’s job count, median wait, median and p90 run time, and success rate.

Started is how reliable the runner is, separate from your tests: the share of jobs sent to it that it picked up. A job counts as missed when it waited 10 minutes and no runner took it. A runner that missed every job still gets a row.

The comparison column lines up the jobs a runner shares with ubuntu-latest (or your busiest runner), so a runner that only takes quick jobs doesn’t look faster than it is.

From an agent

Agents can read the same times through the MCP server, such as “which runner is fastest for test?”.