GitHub-hosted Actions jobs repeatedly fail before runner assignment

[Rehan-The-Analyst]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

GitHub-hosted Actions jobs repeatedly fail before runner assignment — zero steps and BlobNotFound

I am investigating repeated GitHub Actions failures in my repository, Rehan-The-Analyst/BinanceAI.

Multiple hosted jobs fail before any workflow steps execute. The job metadata reports runner ID 0, no runner name, no recorded steps, and no downloadable logs (BlobNotFound).

I created a minimal Ubuntu runner diagnostic that requires no checkout, dependency installation, secrets, external calls, or repository writes. It failed as well, including after one retry.

Evidence

• Minimal runner probe: https://github.com/Rehan-The-Analyst/BinanceAI/actions/runs/40863714431
• Scheduled health report: https://github.com/Rehan-The-Analyst/BinanceAI/actions/runs/40860038169
• Last known successful baseline: https://github.com/Rehan-The-Analyst/BinanceAI/actions/runs/40734039923
• Tracking issue: https://github.com/Rehan-The-Analyst/BinanceAI/issues/134

I checked GitHub Status and attempted to contact GitHub Support, but the support ticket was closed with a recommendation to use self-service resources.

Questions

1. Has anyone resolved this exact failure pattern?
2. Which account-level Actions usage, runner eligibility, or policy settings should I verify?
3. Is there a reliable way to distinguish a hosted-runner provisioning issue from an account restriction when no steps or logs are available?

I have not enabled paid resources, changed repository visibility, merged the pending PRs, or enabled live trading. I would appreciate evidence-based suggestions rather than guesses.

[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. ⭐

[Sagargupta16]

Open one of the failed jobs in the browser and read the Annotations box at the top of the job page; the REST API does not return it. If it says "The job was not started because recent account payments have failed or your spending limit needs to be increased. Please check the 'Billing & plans' section in your settings", then no runner was ever requested, which is exactly the shape you describe: runner ID 0, no runner name, zero steps, BlobNotFound for logs. That is a billing-side refusal, not a provisioning fault and not a repository setting.

Two checks from there. BinanceAI is private (it returns 404 to the public API), so every minute of the scheduled health report draws from the Free plan's included compute, which is now USD 12 per month rather than a fixed minute count and resets on your billing cycle date (https://docs.github.com/en/billing/concepts/product-billing/github-actions). Settings > Billing and licensing > Usage shows this month's Actions figure against that. If it is at the limit, the options are to wait for the reset, add a payment method with a budget, or make the repository public, where standard hosted runners are free. If usage is well under the limit and the annotation still appears, you are in the same wave as several accounts since 2026-10-27 (community discussions 211367, 211502 and 211527: valid cards, budgets under 75%, same message), and only GitHub billing support can clear it; reopen the ticket quoting the annotation text and one run URL, because the self-service redirect usually comes from a ticket that does not name the error.

[christoferpedrosanchezzuzunaga-eng]

Hey @Rehan-The-Analyst,

BlobNotFound before any steps execute points to a storage handshake issue between the Actions runner provisioning layer and Azure Blob Storage (where runner telemetry/token state is stored). When a runner VM spins up, if the SAS token or lease on the storage container expires due to transient latency, the runner terminates immediately.

Two workarounds that usually get you around the bad worker pool:

1. Pin a specific runner version: If you are using ubuntu-latest, try pinning ubuntu-24.04 or ubuntu-22.04 explicitly in runs-on:. That often routes your job away from the affected host cluster.
2. Re-save repository Action permissions: Toggle permissions in Settings > Actions > General to "Disable actions", wait 30 seconds, and re-enable them. That flushes the cached environment tokens for the repository.

[christoferpedrosanchezzuzunaga-eng]

Hey @Rehan-The-Analyst,

BlobNotFound before any steps execute points to a storage handshake issue between the Actions runner provisioning layer and Azure Blob Storage (where runner telemetry/token state is stored). When a runner VM spins up, if the SAS token or lease on the storage container expires due to transient latency, the runner terminates immediately.

Two workarounds that usually get you around the bad worker pool:

1. Pin a specific runner version: If you are using ubuntu-latest, try pinning ubuntu-24.04 or ubuntu-22.04 explicitly in runs-on:. That often routes your job away from the affected host cluster.
2. Re-save repository Action permissions: Toggle permissions in Settings > Actions > General to "Disable actions", wait 30 seconds, and re-enable them. That flushes the cached environment tokens for the repository.