CI failure triage checklist for GitHub Actions

Use this once a week, or whenever the pipeline feels slow and red. The aim is fewer reruns and fewer minutes spent on runs that were going to fail anyway.

Updated 2026-10-17 · Venture Lab 10

Measure first

• Export the last few hundred runs with gh run list --json or the REST API. See the export guide.
• Label every failure with one short cause. Keep the list of labels small and reuse it.
• Look at the failure rate and minutes per workflow. Find which workflow loses the most minutes to failed runs.

Triage the top cause

• Flaky or real? If a rerun of the same commit passes, treat it as flaky and fix or quarantine the test. Do not just rerun.
• Infrastructure or code? Network, registry and runner problems need retries or caching. Code problems need a fix.
• Timeouts. Set timeout-minutes on jobs and steps, so a hung job fails quickly instead of burning minutes.
• Rerun only what failed. GitHub can rerun just the failed jobs, and the jobs that depend on them (POST …/runs/{run_id}/rerun-failed-jobs, or "Re-run failed jobs" in the UI).

Stop wasted runs

• Cancel superseded runs. A concurrency group with cancel-in-progress: true cancels the running job or workflow in the same group when a newer one starts.
• Filter triggers. Use paths filters so documentation-only changes do not run the full build.
• Keep secrets out of logs. They make failure exports risky to share. The free report redacts token-like strings before analysis anyway.

Re-measure

• Export again after the fix and compare the failure rate and minutes lost for the same workflow.

The free CI failure report does the counting in your browser from a CSV with workflow, status, duration_minutes, failure_reason. It reads only the file you paste and does not connect to GitHub.

Venture Lab 10 is independent. Other product and service names are used only to describe compatibility or for comparison, and are trademarks of their owners.

← All guides