GitHub Actions Failing with Zero Steps? Unpacking BlobNotFound Errors for Enhanced Productivity

When GitHub Actions Jobs Fail Before They Even Start: The Zero Steps & BlobNotFound Mystery

Imagine your GitHub Actions workflow kicks off, but then... nothing. The job appears, but with 'zero steps' executed, and any attempt to download logs results in an 'HTTP 404 BlobNotFound' error. This perplexing scenario, recently highlighted in a GitHub Community discussion, signals a failure far upstream of your workflow code. It means the job failed during the critical runner orchestration or provisioning stage, before a runner VM was ever assigned or picked up the job. Consequently, no runner agent started, and no logs were streamed to GitHub's backend storage.

Understanding this specific failure mode is crucial for maintaining seamless CI/CD pipelines and boosting overall developer productivity. Here's a breakdown of common causes and a systematic checklist to resolve them:

1. Quota and Billing Constraints

For private repositories, GitHub Actions minutes are not unlimited. If your account has exhausted its monthly free minutes or if spending limits are set to $0, GitHub will abort jobs before they even reach a runner.

• Check Your Usage: Navigate to your personal GitHub Settings → Billing and plans → Plans and usage. Review the 'Actions & Packages' section to see if your monthly free minutes are consumed or blocked.
• New Account Verification: Newly created accounts might face temporary restrictions. Look for alert banners on your Billing or Security page requesting email/phone verification or a verified payment method.

2. Repository-Level Actions Permissions

Incorrect permissions can prevent workflows from executing.

• Verify Settings: Go to your repository's Settings → Actions → General.
• Ensure 'Allow all actions and reusable workflows' (or appropriate permissions) is selected.
• Under Workflow permissions, confirm that 'Read and write permissions' (or standard read permissions) is enabled.

3. Transient Issues & Deeper Diagnostics

Sometimes, the issue can be transient, or require more detailed investigation.

• Re-run the Job: A quick re-run (Re-run jobs → Re-run failed jobs) can sometimes resolve transient runner provisioning failures.
• Check Annotations: Even with zero steps, the run's annotations might contain the real abort reason.
• Test with a Public Repository: Create a dummy public repository with your minimal workflow. If it passes there, the issue is definitively related to private repository constraints or account verification.
• Inspect Metadata with GitHub CLI: For advanced debugging, use the GitHub CLI to fetch run and job metadata:

  gh api repos/OWNER/REPO/actions/runs/RUN_ID
  gh api repos/OWNER/REPO/actions/jobs/JOB_ID

  Look for the conclusion, timestamps, runner assignment, and any failure details.
• Try a Minimal workflow_dispatch: Test a simple workflow_dispatch job on your default branch to isolate repository-level runner issues from specific workflow configurations.

When to Contact GitHub Support

If the problem persists across re-runs and after checking all the above, especially if it reproduces on a public repository, it's time to contact GitHub Support. Provide the Run ID and Job ID (e.g., 36487651537 and 109148356780 from the original discussion) and mention the 'BlobNotFound' error. For jobs that never reached a runner, only GitHub staff can access the internal runner-side telemetry.

By systematically addressing these potential causes, teams can significantly reduce downtime from these elusive GitHub Actions failures, directly contributing to improved development productivity and more reliable continuous integration.