Auto-retry
Guardrailed automatic retries for transient CI/CD failures — rules scoped by repository, workflow, branch, and job, with backoff and a full audit log.
Transient errors — network timeouts, rate limits, Docker daemon hiccups — should not block a merge queue. Auto-retry re-runs the failed jobs of a run under strict limits, so flaky infrastructure does not look like a real failure.
Creating a rule
Open Auto-retry → New rule.
Pick the repository and workflow the rule applies to — both are required and selected from your synced data, so a rule always targets a concrete pipeline.
Optionally narrow further: a specific branch (or Any branch) and a specific job name.
Choose which conclusion types trigger the retry — failure is on by default; you can add timed_out, cancelled, and action_required.
Set max attempts (1–3 retries) and the retry delay in minutes between them, then save. The rule applies to new failures from that point on.
What a rule matches
A retry fires only when a failed run satisfies every configured condition:
- Repository and workflow — always required.
- Branch — only if you picked one; Any branch matches everything.
- Job name — the run must contain a failed job with that name.
- Conclusion type — the run's conclusion must be one of the selected types.
Rules are scoped by what failed, not by why — there is no free-text or pattern matching on the error output. If a job is flaky, scope the rule to it and let failure triage tell you whether the failures are really transient.
Keep rules on genuinely flaky jobs only. Retrying a deterministic bug wastes minutes and hides real failures — check the retry outcomes in the audit log periodically.
History & value metrics
Every retry event lands in the audit log with its outcome (Recovered or Failed permanently). The page also reports developer hours saved, blocked PRs avoided, and the compute cost spent on retries — so you can prove the rules pay for themselves.
Rule counts depend on your plan.
PR metrics
Delivery analytics for pull requests — velocity, review turnaround, contributor load, discussions, commits, open-PR triage, and AI/bot activity.
Actions inventory
A complete audit of every GitHub Action used across your workflows — categories, SHA pinning, outdated versions, and co-occurrence.