CI got 4m 12s slower: build › Restore Go cache #128
CI on PR #412 took 17m 52s, against 13m 40s usual on main (+31%). Biggest changes:
- build › Restore Go cache +2m 31s (possible cache miss)
- test › go test ./... +1m 09s
This pull request made CI +4m 12s slower.
CI Stats compares each pull request's CI time with recent runs on your default branch and puts the result on the PR as a check, with the jobs and steps responsible. Nothing to add to your workflows.
CI timing
CI time +4m 12s (+31%) vs main
CI took 17m 52s on this PR. On main it usually takes 13m 40s (p90 14m 50s, last 20 runs), so this is outside normal variation. Queue time is excluded (48s).
p50
p50–p90
this PR
| Job | Main | This PR | Change |
|---|---|---|---|
| build | 6m 05s | 8m 57s | +2m 52s |
| test (ubuntu) | 5m 40s | 6m 58s | +1m 18s |
| lint | 1m 55s | 1m 57s | +2s |
Biggest step changes
- build › Restore Go cache+2m 31spossible cache miss
- test › go test ./...+1m 09s
One check on every pull request
The check is called CI timing. Its title in the checks list tells you the answer before you open it.
- CI time 13m 40s, within normal range Nothing to look at. Most PRs land here.
- CI time −3m 05s (−18%) vs main Your change made CI faster. Take the credit.
- CI time +4m 12s (+31%) vs main Slower than normal. The check shows which jobs and steps grew.
- Accepted: +4m 12s (+31%), by @maintainer Expected cost of the change, marked as such with one click.
- Collecting baseline (3 of 5 runs on main) Shown only on a repo with very little history.
Quiet unless it matters
Each PR is compared with a baseline of recent runs on your default branch. Ordinary run-to-run noise is not flagged.
Advisory by default
A slower PR gets a warning, never a red cross. Switch a repo to blocking mode if you want to make the check required.
Queue time kept apart
Waiting for a runner isn't your code's fault. Queue time is shown separately and left out of the comparison.
Set up in a minute
CI Stats reads GitHub Actions webhooks. No workflow edits, no actions to add, no tokens to manage.
-
Install the App
Pick an organisation or individual repositories on GitHub.
-
History is backfilled
Recent runs on your default branch are imported, so there is a baseline straight away.
-
Open a pull request
The first PR after install gets a CI timing check when its workflows finish.
Beyond the pull request
Trends for every workflow
Weekly p50 and p95 per workflow, the jobs and steps growing fastest, and the flakiest jobs by retry rate. A waterfall for each run shows where the time went, queue included.
A monthly report issue
Once a month CI Stats opens an issue in the repo with how CI time moved, so slow drift gets noticed even when no single PR caused it.
Hosted, or on your own servers
The hosted service and the self-hosted build are the same program.
Hosted
Free for public repositories
Install the App and you're done. Pages for public repositories are public; private ones need a GitHub sign-in and access to the repo.
Self-hosted
One binary and PostgreSQL
No Redis, no queue service, and no data sent back to us. Bring your own GitHub App and run it with Docker Compose.
docker compose -f deploy/compose/docker-compose.yml upSource available under the Functional Source License. Each release becomes Apache 2.0 two years after it ships.