GitHub Actions: Inconsistent Workflow Statuses, Missing Logs, and Job Log Retrieval Failures

[the-par3a]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

GitHub Actions: Inconsistent Workflow Statuses, Missing Logs, and Job Log Retrieval Failures

In short: The issue is not simply that some workflows fail. The problem is a potential inconsistency between the reported workflow status and the diagnostic information available for the corresponding run. In some cases, successful runs provide little or no usable job-log information, while failed runs may expose only Error: without sufficient details to identify or explain the underlying failure.

Hi everyone,

I have been experiencing unusual and inconsistent behavior with GitHub Actions across multiple workflows and repositories, and I wanted to ask whether anyone else has encountered something similar.

The issue does not appear to be limited to one specific workflow, repository, API operation, or account.

In some cases, a workflow completes successfully and receives a green Success check, but the available job logs are empty or contain very little useful information.

In other cases, GitHub reports a workflow as Error/Failure, but the available job logs do not provide a meaningful explanation of what went wrong. In some cases, the log appears to contain only:

Error:

and nothing else.

This makes it difficult to determine whether the problem is related to the workflow itself, the Actions runner, an API operation, or GitHub Actions' logging and status-reporting infrastructure.

Examples

I have observed this behavior across multiple workflows and repositories, including:

• the-par3a/ticketing
• the-par3a/ticketing-v1
• steven750MC/WebAppCapsule

Example workflow runs and job log URLs

Some example runs:

• https://github.com/the-par3a/ticketing/actions/runs/34051609230
• https://github.com/the-par3a/ticketing/actions/runs/34051609230/job/101536125156
• https://github.com/steven750MC/WebAppCapsule/actions/runs/34050259059
• https://github.com/the-par3a/ticketing/actions/runs/34052666853/job/101538948130
• https://github.com/the-par3a/ticketing-v1/actions/runs/34053251424/job/101540504088
• https://github.com/the-par3a/the-par3a/actions/runs/34051459889/job/101535729002
• https://github.com/the-par3a/the-par3a/actions/runs/34054635383/job/101544168749
• https://github.com/the-par3a/ticketing-v1/actions/runs/34055168220/job/101545679204
• https://github.com/the-par3a/ticketing-v1/actions/runs/34083950118/job/101624329407
• https://github.com/the-par3a/test-workflow/actions/runs/34092444138/job/101648615832

These are examples of the broader behavior I am observing. I am not claiming that all of these runs have the exact same underlying cause.

A concrete failure example

One particularly clear example occurred in the-par3a/ticketing in a workflow called 🕊️ Sweet Ending.

• Job log: https://github.com/the-par3a/ticketing/actions/runs/34051609230/job/101536125156
• Run: #6
• Run ID: 34051609230
• Event: workflow_dispatch
• Approximate time: 2026-09-06 18:24:26 UTC

The workflow completed most of its steps successfully before failing during an API operation.

The failing request was:

POST /repos/the-par3a/ticketing/issues/9/pin

GitHub CLI returned:

gh: Not Found (HTTP 404)
{
  "message": "Not Found",
  "status": "404"
}

The workflow then reported:

❌ Goodbye Issue could not be pinned.
##[error]Process completed with exit code 1.

This is a useful concrete example, but I do not believe the overall issue is necessarily related to this particular workflow or API request.

The more general issue I am trying to investigate is the inconsistency between the workflow result and the diagnostic information that GitHub Actions provides for the run.

What I am seeing

The behavior can be summarized as follows:

• A workflow can show Success while its job logs are empty or contain little useful information.
• A workflow can show Error/Failure without a meaningful explanation in the available logs.
• In some cases, the log appears to contain only Error: with nothing after it.
• In other cases, an actual error is visible, but the available information still does not clearly explain the overall failure.
• Similar unusual behavior has appeared across different workflows and repositories.

Because of this, I am wondering whether this could be related to GitHub Actions itself rather than a problem with one particular workflow.

What I have checked

For the concrete failing workflow, the relevant permissions are present, including:

• Contents: write
• Issues: write
• PullRequests: write
• Metadata: read

The preceding authentication and Issue-creation steps also complete successfully.

I have also verified that other workflows are able to execute successfully.

So this does not appear to be a simple case of Actions being completely unable to run in the repository.

What is particularly unusual is that both successful and failed runs can sometimes have insufficient or unexpected diagnostic information.

Another account

I have also noticed unusual GitHub Actions behavior on another GitHub account that is not owned by me:

steven750MC/WebAppCapsule

I cannot confirm that this account is experiencing the exact same underlying error as the ticketing workflow, so I do not want to assume that the two cases are directly related.

However, seeing unusual Actions behavior on a separate account makes me wonder whether this could be a broader GitHub Actions issue rather than something isolated to my repository.

What I would appreciate from GitHub

If possible, I would appreciate clarification or assistance regarding the following points:

1. Whether there are any known incidents or ongoing issues affecting GitHub Actions log availability, storage, or retrieval.

2. Whether the observed log-retrieval flow — where the GitHub API responds with an HTTP 302 redirect to a temporary storage URL — is operating as expected.

3. Whether a failure while retrieving the underlying log object from the temporary storage endpoint could result in incomplete, empty, or Error:-only logs being displayed in the GitHub Actions UI.

4. Whether the affected workflow runs could be investigated using GitHub's internal server-side logs or diagnostic information that is not available to users through the Actions interface or public API.

5. Whether there is any known relationship between the behavior I am observing and the temporary Azure Blob Storage endpoints used to host and deliver GitHub Actions job logs.

Any clarification, investigation, or additional diagnostic information would be greatly appreciated, as it could help determine whether the issue is related to log storage, retrieval, network connectivity, or another part of the GitHub Actions infrastructure.

I would also appreciate knowing whether there have been any recent changes or incidents affecting GitHub Actions logging, workflow status reporting, runners, or the Issues API.

The HTTP 404 in my concrete example may have a separate explanation, but the broader issue I am trying to understand is the inconsistency between the reported workflow result and the diagnostic information provided by GitHub Actions.

If anyone has experienced something similar or has an explanation for this behavior, I would be very interested to hear about it.

What this issue is not

I am not reporting that all GitHub Actions workflows are failing.

I am also not claiming that every example listed above has the same underlying cause.

The specific issues/9/pin 404 example may have an independent explanation.

The issue I am primarily investigating is the inconsistent availability and diagnostic quality of workflow logs, together with the mismatch that can occur between workflow status and the diagnostic information available for that run.

Evidence Summary

The behavior I am investigating currently falls into several related categories:

• Successful runs with insufficient diagnostic information — some workflow runs complete successfully, but their available logs contain little or no useful information.
• Failed runs with incomplete diagnostics — some failed runs provide only Error: or otherwise insufficient information to identify the cause.
• Previously accessible logs becoming unavailable — some older workflow logs that were previously available later became inaccessible or incomplete.
• Behavior across multiple repositories and workflows — the pattern is not limited to a single workflow definition or repository.
• Behavior observed outside my own repositories — similar unusual behavior has also been observed in another account, although I cannot confirm that it has the same root cause.
• API-level investigation — direct testing of the workflow-job log API showed that GitHub can return an HTTP 302 redirect to a temporary storage URL, after which the connection to the redirected endpoint can fail.

Supporting screenshots and additional examples

Screenshot — workflow log example

Screenshot — workflow log example

https://github.com/the-par3a/ticketing-v1/actions/runs/34053251424/job/101540504088

Screenshot — ticketing-v1 job

https://github.com/the-par3a/the-par3a/actions/runs/34051459889/job/101535729002

Screenshot — the-par3a job

https://github.com/the-par3a/the-par3a/actions/runs/34054635383/job/101544168749

Screenshot — the-par3a job

https://github.com/the-par3a/ticketing-v1/actions/runs/34055168220/job/101545679204

Screenshot — ticketing-v1 job

https://github.com/the-par3a/ticketing-v1/actions/runs/34083950118/job/101624329407

Screenshot — ticketing-v1 job

https://github.com/the-par3a/test-workflow/actions/runs/34092444138/job/101648615832

Multiple screenshots — test-workflow job

Update 1

I have now observed additional evidence suggesting that this issue may be more widespread than initially reported.

The behavior does not appear to be limited to my account or repositories. I have also noticed cases involving GitHub's own Community Actions where the workflow logs appear to be empty or provide little to no useful diagnostic information.

This makes me more confident that the issue may not be specific to my workflows or repositories. I am continuing to investigate and collect examples to determine how widespread the behavior is.

I will update this discussion if I find additional relevant information or clearer examples.

https://github.com/community/community/actions/runs/34096406376/job/101660927301

Screenshot — GitHub Community Actions job

https://github.com/community/community/actions/runs/34033068914/job/101486099501

Screenshot — GitHub Community Actions job

Update 2

I have continued testing the issue and, based on the additional tests I have performed, it now seems possible that the problem may be originating on GitHub's side.

This is not a confirmed conclusion yet, and I cannot say with certainty that the issue is caused by GitHub. However, the behavior I am observing across different workflows and repositories makes a GitHub-side issue seem increasingly possible.

I will continue testing and collecting evidence before drawing any definite conclusions.

If possible, I would also appreciate it if GitHub could review the relevant server-side logs and internal diagnostic information for these workflow runs. There may be information at the server or infrastructure level that is not exposed in the workflow logs available to users, which could help determine where the issue is occurring.

Update 3

After conducting extensive additional testing, I have found no indication that this issue is caused by any restriction or limitation on my account or IP address.

I tested the behavior across different workflows, repositories, and Actions operations, and the issue continued to occur independently of the specific workflow or repository involved.

Based on these tests, I currently have no evidence that my account or IP address is being restricted or rate-limited.

I cannot confirm with certainty that the issue is originating on GitHub's side, but based on the evidence I have collected so far, I believe this is the more likely possibility.

I will continue monitoring and testing the behavior to see whether this conclusion remains consistent.

Update 4

I have now observed an additional pattern that further increases my suspicion that this may be a GitHub-side issue.

The issue initially appeared to affect newer workflow runs, but over time, the same behavior began affecting older runs as well. Some workflow runs and logs that were previously visible and accessible are now missing or no longer provide the information they previously did.

I can confirm that these older logs were available before, as I had personally used them to debug my workflows and code. They had also not reached their normal expiration period.

At the same time, newer workflow runs are continuing to show the same unusual behavior, with some logs containing only:

Error:

and no additional diagnostic information.

I still cannot confirm that the root cause is on GitHub's side, but based on the progression of the issue, the disappearance of previously available logs, and the fact that the same behavior continues to affect newly created workflow runs, a GitHub-side server or infrastructure issue currently seems increasingly likely.

I will continue monitoring the situation and testing additional workflow runs. If the behavior changes or I find more concrete evidence, I will update this discussion accordingly.

Update 5 — Technical finding: failure after the GitHub API redirect

I have continued investigating this issue and attempted to identify the underlying cause and find a way to work around it.

To investigate the problem more precisely, I started working directly with the GitHub API and then developed a small Python application to analyze workflow runs and retrieve their logs programmatically. This application will be published on GitHub soon so that others can also use it to investigate similar issues.

During this process, I was able to identify a more specific point of failure in the log-retrieval process.

Based on my tests, the GitHub API itself is not the part failing. When requesting a workflow job's logs, GitHub successfully responds with a 302 redirect to a temporary Azure Blob Storage URL where the actual log file is hosted.

The failure occurs after the redirect, when my application attempts to establish a connection to that temporary Azure Blob Storage URL. The connection is refused and results in:

HTTPSConnectionPool(...)
Max retries exceeded with url: .../logs/job/job-logs.txt
Caused by NewConnectionError(...)
[WinError 10061] No connection could be made because the target machine actively refused it

This strongly indicates that the failure is occurring during the connection to the temporary Azure Blob Storage endpoint rather than during the original GitHub API request.

In other words, the process appears to work as follows:

GitHub API
    ↓
Request workflow logs
    ↓
GitHub returns HTTP 302
    ↓
Temporary Azure Blob Storage URL
    ↓
Connection attempt
    ↓
Connection refused (WinError 10061)

The GitHub API is therefore successfully processing the request and returning the temporary log URL, while the subsequent connection to the Azure-hosted log endpoint is where the failure occurs.

Based on this investigation, I no longer believe that the GitHub API itself is the direct source of this particular connection failure. The evidence instead points toward the Azure Blob Storage endpoint or the network path between my system and that endpoint.

I cannot determine from WinError 10061 alone whether the connection is being refused directly by the Azure endpoint or whether something in the network path is preventing the connection. However, the failure clearly occurs after the GitHub API redirects the request to the temporary Azure-hosted log URL.

This finding gives me a much clearer technical direction for further investigation and may also help explain why some workflow runs exist while their logs are unavailable, incomplete, or contain only Error:.

I will publish the Python application and its findings on GitHub soon and continue updating this discussion as I obtain more evidence.

Thank you in advance to everyone who will take the time to read through this, share their thoughts, and help investigate the issue. I really appreciate everyone's input and support. ❤️

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

[steven750MC]

I can confirm that I am experiencing the same issue with GitHub Actions on my account as well. I have encountered workflow runs with unexpected statuses, including cases where a run reports an error but the logs provide little to no useful information about what actually went wrong.

I am also in contact with the person who reported the issue above, and I can confirm from my own experience that this behavior is not limited to their account. I have personally encountered similar GitHub Actions behavior on my own account.

[the-par3a]

Just to clarify: the steven750MC account is not my account. I am in contact with the owner of that account, and I’m aware of some similar GitHub Actions behavior there as well.

I’m mentioning it only as an additional example, and I cannot confirm whether the behavior has the exact same root cause as the issue described above.

[YugPatelStarDev]

Yeah, that does sound pretty weird, especially if you're seeing it across different repos and workflows.

The empty Error: logs would probably be the part I'd focus on. A normal workflow failure should usually give you something useful to work with, even if the actual problem is in the workflow.

For the /issues/9/pin example, the 404 could have its own reason, like permissions, the issue not being available to the token, or the API request itself. But that doesn't really explain the other runs where the status and logs don't seem to match.

If you're seeing the same thing across multiple accounts/repos, I'd be more suspicious of an Actions/runners/logging issue than one broken workflow.

I'd probably report a couple of the clearest examples to GitHub Support rather than all of the runs. Having one successful run with basically no logs and one failed run showing just Error: should make the issue pretty easy for them to investigate on their side.

Hopefully someone else here has seen the same thing recently.

[the-par3a]

(cc @YugPatelStarDev ) Thanks for your input and for taking the time to look into the examples I provided. I especially appreciate your suggestion about focusing on the empty Error: logs, as I agree that they are one of the clearest and most unusual parts of the issue.

The reason I provided a relatively large number of examples is that I wanted to show that this does not appear to be an isolated problem with a single workflow. If I had only provided one or two runs, I think the investigation could easily have been directed toward a problem with that particular workflow.

Based on my initial checks, I don't believe this is a structural workflow problem, such as a broken or invalid .yml file. GitHub normally reports workflow-file or configuration problems in the workflow file section, and if the workflow itself were invalid, it generally would not execute normally in the first place. That is not what I'm seeing here.

The main issue I'm reporting is the lack of useful diagnostic information. In some cases, the workflow runs and performs several operations successfully, but the resulting logs provide little or no information about what actually happened. In other cases, a run reports a sucesswhile the available logs are essentially just Error:.

That's why I included multiple links and examples. The behavior appears broad enough that I felt it was important to provide enough evidence to demonstrate the pattern across different workflows, repositories, and, in one case, another account as well.

I agree that GitHub Support may be able to investigate this further from their side, especially because they may have access to runner or internal logging that isn't visible to us.
( im replying to this message:

Yeah, that does sound pretty weird, especially if you're seeing it across different repos and workflows.

The empty Error: logs would probably be the part I'd focus on. A normal workflow failure should usually give you something useful to work with, even if the actual problem is in the workflow.

For the /issues/9/pin example, the 404 could have its own reason, like permissions, the issue not being available to the token, or the API request itself. But that doesn't really explain the other runs where the status and logs don't seem to match.

If you're seeing the same thing across multiple accounts/repos, I'd be more suspicious of an Actions/runners/logging issue than one broken workflow.

I'd probably report a couple of the clearest examples to GitHub Support rather than all of the runs. Having one successful run with basically no logs and one failed run showing just Error: should make the issue pretty easy for them to investigate on their side.

Hopefully someone else here has seen the same thing recently.

[the-par3a]

A small follow-up to Update 5: Further testing and review of GitHub's documentation suggest that the issue may be related to the storage/delivery path used for GitHub Actions job logs.

I’m still investigating whether the connection refusal is related to the temporary Azure-hosted endpoint or the network path to it. I don’t have enough evidence to identify the exact cause yet, but this gives me a more specific direction for further investigation.

[Modell3105]

We are seeing a very similar GitHub Actions problem in our private repository Modell3105/Alex-is-AI-MIND-ALIGNMENT.

The important difference is that GitHub does create the job, but it fails before any workflow step starts.

Concrete examples:

• ALEX Actions Diagnostic

  • Workflow ID: 354202377
  • Run ID: 34721256832
  • Job ID: 103632496656

• ALEX Security

  • Run ID: 34721256820
  • all three jobs fail before steps execute

The pattern is:

• The workflow is discovered correctly.
• A job object is created.
• The job immediately fails.
• steps: []
• No runner logs are available.
• Fetching the job logs returns BlobNotFound.
• Even actions/checkout, npm, TypeScript, tests and build are never reached.

Our diagnostic workflow is intentionally minimal: it only runs one echo step on ubuntu-latest. Even that step never executes.

Our GitHub Actions budget is also not exhausted.

This therefore does not appear to be an application, YAML, TypeScript or build problem. It looks like a failure before step execution, potentially in GitHub Actions job dispatch / runner provisioning or related infrastructure.

Could GitHub please check the server-side information for runs 34721256832 and 34721256820?