How to find your slowest CI jobs with CI Insights

Job-level data comes from the CI provider itself, so there is nothing to instrument. Enable CI Insights on your repositories from the GitHub integration page in the dashboard, then re-run a workflow or push a commit. Durations, execution counts, failure rates, and cost show up on the Jobs page on the next run. Jenkins and Buildkite have their own setup guides and land in the same view.

Two controls do most of the work on that page. The date range selector sets the window your percentiles are computed over, and the grouping options let you split the same job by branch, runner group, or label. Grouping is how you catch the job that is fine on main and awful on pull requests, or fine on one runner label and awful on another.

Each job also carries a health status of healthy, flaky, or broken, based on its recent run history. A flaky job is one that produced two different conclusions on the same commit, which is a fact about your CI rather than an opinion about it. If flakiness is what you are chasing rather than duration, stopping flaky tests from blocking your merge queue picks up from there.

Sort by duration, note the p95 rather than the average, then multiply by executions. Say a 30-day window on one repository comes back looking like this:

The numbers are made up, the shape is not: the job everyone names ends up fourth on the list. Ranked by single-run duration, e2e-nightly wins by a mile. Ranked by total time, it costs a tenth of what integration-tests does, and speeding it up would change nobody's afternoon.

The gap between p50 and p95 is the second signal to read. A tight spread means a job that behaves, and shaving it takes real engineering. A p95 at double the median means something intermittent is going on, usually a shared service that times out or a cache that misses. That one is often cheap to fix once you can see it, which is why it is worth opening the executions view and clicking into the slow runs directly. Each execution has a detail panel with the full job timeline and the test results that came with it, so you can trace a regression back to the commit that introduced it.

A job that spends six minutes queued and four minutes running reports ten minutes, and every hour you spend adding caches to it will buy you nothing. The Runners page splits those apart. Configure which runner groups to track first, optionally filtered by label, then expand any runner row to get duration percentiles at median, p95, and p99, queue time broken out separately, total runs, failure rate, and cost.

Each runner also gets a health status of healthy, unstable, or degraded, scored against its own group, so a node that is limping shows up next to peers doing the same work rather than in the abstract. High queue times across a whole group point at fleet capacity. One runner underperforming its group points at that box. The runners documentation covers the fleet configuration, and we have no reason to push you toward any particular provider, since we do not sell runners.

Do this before you touch any test code. Roughly half the "slow CI" complaints we see resolve into "the fleet is too small at 10am", and that is a purchasing decision rather than an engineering project.

The cheapest minute is the one you never spend. Look back at build-docker: nine minutes, sixty times a day, on every pull request whether or not the change could possibly affect the image. Making it faster is a week of work. Not running it on documentation changes is an afternoon.

Declare the areas of your repository as scopes in .mergify.yml:

scopes:
  source:
    files:
      web:
        include:
          - apps/web/**/*
      api:
        include:
          - services/api/**/*
      docs:
        include:
          - docs/**/*

Then have one small job resolve the scopes for the pull request and gate the expensive jobs on the ones they cover:

jobs:
  detect-scopes:
    runs-on: ubuntu-24.04
    outputs:
      api: ${{ fromJSON(steps.scopes.outputs.scopes).api }}
    steps:
      - uses: actions/checkout@v5
      - id: scopes
        uses: Mergifyio/gha-mergify-ci@v25
        with:
          action: scopes

  integration-tests:
    needs: detect-scopes
    if: ${{ needs.detect-scopes.outputs.api == 'true' }}
    uses: ./.github/workflows/integration-tests.yaml
    secrets: inherit

The scopes action inspects the diff and returns a JSON map of scope names set to true or false, which each downstream job reads in its if condition. Add a final gate job using the wait-jobs action and make that one status required in your branch ruleset, so skipped jobs never look like missing coverage. Full setup is in the monorepo CI documentation, and the monorepo CI guide covers when this pays off and when it does not.

The same scopes then feed the merge queue. When Mergify assembles a batch it prefers pull requests that share scopes, so a batch tends to need one CI run rather than one per change, and a failure inside it is cheaper to bisect. If you do not have a queue yet, start with setting one up on GitHub, then come back and wire the scopes in. What to watch once it is running is covered in queue analytics.

CI gets slow the way weight gets gained, half a minute at a time, and nobody notices until the number is embarrassing. The fleet view carries a week-over-week comparison so you can answer "is CI getting worse" without building a dashboard for it. Pair it with the Slack integration for the job outcomes you care about, and with the PR summary comments that post what broke and where, so a regression gets caught by the person who introduced it instead of by the whole team a month later.

Re-run the ranking once a month. It takes ten minutes and the answer changes, because the job you fixed drops off the list and something you have never looked at moves up.