Re-run rate is a useful but partial friction signal. It shows how often developers retry a security job on the same commit. A high rate suggests distrust or flakiness. It does not show who gave up, bypassed the check or never pushed. Use it with other measures.
What re-run rate captures
When a developer clicks re-run on a failed security job, they are telling you something. Either they think the failure was not real, or they hope it will pass the second time. Both mean the check did not earn their trust on the first try.
On GitHub, a re-run uses the same commit SHA and ref as the original run, and a run can be re-run up to 50 times within 30 days. That means you can count re-runs per commit cleanly. Other CI systems have retry buttons that behave similarly.
How to compute it
- For each security job, count attempts per commit.
- Re-run rate is commits with two or more attempts, divided by commits with at least one attempt.
- Split by outcome of the first attempt. Re-runs after a failure are the interesting ones.
- Add a second view: of the re-runs after failure, how many flipped to pass without a code change? That is the flake signal.
Keep the data by repository, not by person. You are measuring the check, not the developers.
What it does not capture
| Behaviour | Seen in re-run rate? |
|---|---|
| Developer retries a flaky job | Yes |
| Developer pushes a small change to retry | Partly, as a new commit |
| Developer asks for a bypass | No |
| Developer disables or skips the job | No |
| Developer delays opening a pull request | No |
So a low re-run rate does not prove low friction. It might mean people stopped bothering. Pair it with bypass and override counts, and with time from first failure to merge.
Reading the signal
A rising re-run rate after a change in rules or scanner version is a strong hint the change introduced noise. A steady, high rate on one repository points to something local, such as a slow network from that runner pool. A steady, low rate with many overrides suggests the check is seen as an obstacle to route around.
When you see a high rate, read ten recent failing runs by hand. Numbers tell you where to look. Reading the logs tells you why.
Acting on it
- Fix the top flaky jobs first. See the post on measuring flake rate.
- Improve the failure message so the first failure is understood, which reduces blind retries.
- Share the number with the team that owns the pipeline template, not as a scorecard against developers.
Quick check
Should we set a target re-run rate?
A target invites gaming, such as hiding the re-run button. Track the trend and investigate jumps.
Are re-runs always bad?
No. Re-running after a real infrastructure outage is healthy. The signal is in re-runs that flip without any change to code or environment.
How Safeguard fits
Safeguard offers policies, gates and guardrails with dependency and SBOM scanning, and gate results link to specific findings, which helps developers understand a failure instead of retrying it. Try the free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs, Re-running workflows and jobs: https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/re-running-workflows-and-jobs
Last reviewed: 19 October 2026.
