GitHub Actions jobs fail before all steps with BlobNotFound and no logs or artifacts

[rishablodha1712-eng]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

Six independent GitHub Actions jobs in a private repository fail before any visible workflow step executes.

Observed behaviour:

• no “Set up job” or other recorded steps;
• no downloadable logs;
• no artifacts;
• every job-log request returns BlobNotFound;
• rerunning the individual jobs repeatedly produces the identical result;
• all jobs use GitHub-hosted Ubuntu runners;
• no repository code was changed during the investigation.

Pull request:
PR #154 — P0: complete opportunity intelligence recovery

Affected workflows and latest retries:

1. Quality Gate
   Run: 30191465357
   Retry job: 89780671112

2. Live Runtime Cutover Pack Quality
   Run: 30191465336
   Retry job: 89780672436

3. Native Analysis Artifact Ledger Quality
   Run: 30191465352
   Retry job: 89780673825

4. Brave Search Provider Quality
   Run: 30191465354
   Retry job: 89780674899

5. Retrieval Provider Quality
   Run: 30191465335
   Retry job: 89780676997

6. Atomic Reviewed Decision Quality
   Run: 30191465334
   Retry job: 89780678073

Latest repeated-failure window:
2026-07-26 09:50:57–09:51:11 UTC

The jobs fail before any visible step and expose no usable error. The original runs and multiple retries all return the same BlobNotFound log-storage response.

Local validation for the pull-request scope completed successfully:

• TypeScript check passed;
• strict lint passed;
• deterministic P0 regression checks passed;
• MCP contract checks passed;
• direct Next.js production build passed.

This does not appear to be a normal workflow assertion failure because no runner step or log is created.

Questions:

1. Can this be caused by a GitHub Actions runner-provisioning or log-storage issue?
2. Why do newly completed jobs immediately return BlobNotFound?
3. Is there an account/repository Actions setting that could cause jobs to fail before “Set up job”?
4. How can the failed checks be regenerated after the service issue is corrected?

The repository is private, so I can provide sanitized workflow YAML if needed. No secrets are included here.

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

[Beno-Goulart]

Hi,

The fact that all six jobs fail before "Set up job", produce no logs, and immediately return BlobNotFound makes this sound less like a workflow issue and more like an infrastructure problem on the GitHub Actions side.

If the runner never reaches the setup phase, there's very little your workflow can do to cause this behavior. The missing logs and artifacts across multiple independent jobs also suggest that log generation or storage may have failed before execution could begin.

Once the underlying issue is resolved, rerunning the failed jobs or pushing a new commit should regenerate the checks. If the problem persists, I'd recommend opening a GitHub Support ticket and including the affected run IDs, since they can inspect the backend logs that aren't available to repository maintainers.

Hopefully this turns out to be a temporary service issue rather than a problem with your workflows.

[jrb00013]

yeah this does not look like a normal test failure. if you never even get “Set up job”, there’s no runner log blob to download — so BlobNotFound on the log endpoint is a symptom, not your assertion failing.

what that pattern usually means:

• job dies (or never properly starts) during provisioning / log-store handoff
• github never writes the job log object
• UI retries ask for a blob that was never created → BlobNotFound
• same thing on every re-run of those jobs = service-side or account/runner routing issue, especially when local TS/lint/build all pass

answers to your questions

1. can it be runner-provisioning / log-storage?
   yes. that’s the leading explanation when multiple independent jobs all fail before steps with identical BlobNotFound and zero artifacts.

2. why newly completed(?) jobs immediately BlobNotFound?
   the job record exists, but the log backend never got a payload (or lost it). “completed/failed” in the checks UI can still point at empty log storage.

3. Actions setting that fails before Set up job?
   uncommon for this exact fingerprint. billing locks / Actions disabled usually block the whole workflow with a clear banner, not silent pre-step BlobNotFound on a subset of jobs. still worth checking: repo Actions enabled, org policy not blocking github-hosted runners, no spending limit hard-stop mid-fleet. but your “six jobs, same window, no steps” screams platform more than a mis-set secret.

4. how to regenerate checks after it’s fixed?
   empty commit / gh workflow run / re-run failed jobs / close-reopen PR once github status recovers. if BlobNotFound persists on brand-new run IDs, it’s still broken upstream — re-running the same dead job ids won’t help.

what i’d do next

• check https://www.githubstatus.com for Actions incidents around 2026-07-26 09:50 UTC
• kick one brand-new workflow_dispatch (not a retry of the cursed job ids). if that also BlobNotFound’s with no Set up job → open Support with the run/job ids you listed
• temporarily simplify one failing workflow to a single runs-on: ubuntu-latest + run: echo hi job. if even that can’t produce logs, it’s 100% infra
• paste sanitized workflow runs-on / concurrency / environment: blocks if you want a second pair of eyes, but i wouldn’t expect YAML to explain “no Set up job + BlobNotFound”

bottom line: treat this as an Actions log/runner platform fault until a fresh trivial workflow can produce real logs again. your local green checks support that.