GitHub Actions jobs fail with zero steps and BlobNotFound logs

[tasinkhan9698]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

Hi everyone,

I am investigating repeated GitHub Actions failures in my repository:
https://github.com/tasinkhan9698/SHADOW-RUNE

Even a minimal diagnostic workflow with only an ubuntu-latest runner and a single echo command fails.

Diagnostic details:

• Branch: security/bugfix-fail-closed-auth
• Commit: 7ec5a3e7249fc1bb7022842a6e57c6fb456737c6
• Run ID: 36487651537
• Job ID: 109148356780

The job fails with no steps. The job steps API returns an empty array (steps: []), and downloading the logs returns HTTP 404 with BlobNotFound.

What should I check to determine why the job has no steps or available logs?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[UmeshCode1]

Hi @tasinkhan9698!

When a GitHub Actions job fails with steps: [] (zero steps) and downloading logs returns HTTP 404 BlobNotFound, it indicates that the failure occurred during the runner orchestration / provisioning stage before a runner VM was ever assigned or picked up the job.

Because no runner VM ever initialized, no runner agent was started, and no logs were streamed to GitHub's backend storage (hence Azure BlobNotFound).

Here is what causes this and the exact checklist to resolve it:

---

1. Private Repository Actions Quota & Spending Limit

Looking at your account profile, SHADOW-RUNE appears to be a private repository:

• Free Plan Limits: Private repositories have a monthly limit of 2,000 Actions minutes. If your account has consumed its monthly allotment or if your spending limit is set to $0 (the default) with exhausted minutes, GitHub will immediately abort incoming jobs before queueing a runner.
• Where to check:
  1. Go to your personal GitHub Settings (top-right avatar $\rightarrow$ Settings).
  2. Click Billing and plans $\rightarrow$ Plans and usage.
  3. Scroll down to Actions & Packages. Check whether your monthly free minutes are at 100% or blocked.

---

2. New Account Verification & Anti-Abuse Checks

For newly created accounts (created within the last few weeks) running workflows in private repositories, GitHub's automated abuse-prevention system sometimes holds runner dispatch until account verification is complete:

• Check if there is an alert banner on your Billing or Security page requesting email verification, phone verification, or a verified payment method on file to unlock compute resources.

---

3. Repository-Level Actions Permissions

Check your repository settings for permission restrictions:

1. Go to SHADOW-RUNE $\rightarrow$ Settings $\rightarrow$ Actions $\rightarrow$ General.
2. Under Actions permissions, verify that "Allow all actions and reusable workflows" (or appropriate permissions) is selected, not disabled.
3. Under Workflow permissions, ensure "Read and write permissions" (or standard read permissions) is enabled.

---

4. How to Verify / Test Instantly

To confirm whether this is a private-quota/account constraint:

1. Create a dummy Public repository with your minimal test workflow (ubuntu-latest with run: echo "test").
2. Trigger the workflow.

• If it passes on the public repository: This definitively confirms that the workflow syntax and runner platform are fine, and the failure on SHADOW-RUNE is due to private repository compute quotas, spending limits, or account billing verification.
• If it also fails on the public repository: Your account's Actions execution may be temporarily restricted by GitHub trust & safety, and you will need to open a ticket at GitHub Support.

[kurupdevs]

The combination of zero steps and BlobNotFound is itself the diagnosis: the job failed before any runner ever reported step execution, so there were never any logs to upload in the first place. The 404 on the log download isn't a permissions problem — the blob simply doesn't exist because nothing was ever written.

A few concrete next checks:

1. Re-run the failed job once (Re-run jobs → Re-run failed jobs). If it passes on retry, this points at a transient runner provisioning/pickup failure rather than anything in your workflow.
2. Check the run's annotations, and whether even the "Set up job" step exists. Annotations sometimes carry the real abort reason (e.g. a provisioning error) even when the steps list is empty.
3. Confirm Actions is actually enabled for that branch and repository — repository Settings → Actions permissions, and that workflow permissions aren't blocking it. Your minimal echo workflow already rules out a YAML/syntax problem, so the failure is happening upstream of execution.

One note on log retention: GitHub-hosted logs are deleted after the retention period, and downloads then return 404 too — but this run is fresh, so that doesn't apply here.

If it reproduces on re-run, open a ticket with GitHub Support quoting Run ID 36487651537 and Job ID 109148356780. For a job that never reached a runner, only GitHub staff can see the runner-side telemetry, so there's a limit to what the forum can diagnose.