GitHub Actions step logs endpoint returns 404 while job-level logs download successfully

[JoyForCode]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

API

Body

6_Retrieve Failed Step Logs.txt

Summary

I'm experiencing an issue with the GitHub Actions REST API endpoint for downloading individual workflow step logs.

The following endpoint consistently returns 404 Not Found for a completed workflow job:

GET /repos/{owner}/{repo}/actions/jobs/{job_id}/steps/{step_number}/logs

However, the job metadata endpoint and the job-level logs endpoint work successfully using the same repository, authentication token, job ID, and API version.

Environment

• Repository: JoyForCode/aws-terraform-configs
• API version: 2026-03-10
• Client: Octokit REST.js v22.0.1
• Runtime: Node.js 24
• Authentication: GitHub Actions GITHUB_TOKEN / fine-grained PAT
• Required permission: Actions: read

Reproduction steps

1. Trigger a GitHub Actions workflow that fails during one of its steps.
2. Retrieve the job details:

GET /repos/{owner}/{repo}/actions/jobs/{job_id}

This returns 200 OK, including the job's step metadata.

3. Identify a failed step from the returned steps array. For example:

{
  "name": "Check Terraform Formatting",
  "conclusion": "failure",
  "number": 4
}

4. Request the individual step logs:

GET /repos/{owner}/{repo}/actions/jobs/{job_id}/steps/4/logs

Actual result: 404 Not Found, with the response body:

{
  "message": "Not Found",
  "status": "404"
}

5. Request the complete job logs:

GET /repos/{owner}/{repo}/actions/jobs/{job_id}/logs

Actual result: 200 OK after the redirect is followed. The complete job log is successfully downloaded.

6. Request the complete workflow-run logs:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Actual result: 200 OK. The response is a ZIP archive containing workflow logs.

Expected behaviour

According to the REST API documentation, the individual step-logs endpoint should return 302 Found with a redirect URL to download the plain-text logs for that specific step.

I would expect the endpoint to return the redirect URL for a valid job ID and step number when the job has completed and its logs are available.

Actual behaviour

• Job metadata endpoint: 200 OK
• Job-level logs endpoint: 200 OK
• Workflow-run logs endpoint: 200 OK
• Individual step-logs endpoint: 404 Not Found

The same authentication credentials and API version are used for these requests.

I have also verified that the requested step number matches the number field returned by the job metadata endpoint.

Questions

1. Is the individual step-logs endpoint currently supported for all GitHub Actions workflows and completed jobs?
2. Are there additional requirements or restrictions for retrieving individual step logs?
3. Could this be an issue with the endpoint or the availability of step-level log artifacts?
4. Is there a known limitation or recommended alternative for retrieving individual step logs?

References

• [GitHub REST API: Workflow jobs](https://docs.github.com/en/rest/actions/workflow-jobs)
• [Download step logs for a workflow run job](https://docs.github.com/en/rest/actions/workflow-jobs#download-step-logs-for-a-workflow-run-job)
• [Download job logs for a workflow run](https://docs.github.com/en/rest/actions/workflow-jobs#download-job-logs-for-a-workflow-run)

I can provide additional request IDs, timestamps, and sanitized API responses if needed.

Thank you!

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

[Manishram-ai]

I can reproduce this on a public repo too. For a completed job in mdn/browser-compat-data (run 41591314160), GET /repos/{owner}/{repo}/actions/jobs/{job_id}/steps/{step_number}/logs returns 404 for every step, with X-GitHub-Api-Version set to 2026-03-10 and to 2022-11-28, while /actions/jobs/{job_id}/logs for the same job returns the log. So it isn't your token, permissions or step numbers. The endpoint is documented but doesn't seem to be serving yet, which makes this one for the Actions team.

Until it works, the run logs ZIP has the same thing. After the run finishes, GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs contains one file per step, named <job name>/<step number>_<step name>.txt, and the number matches number in the job's steps array. Your attachment, 6_Retrieve Failed Step Logs.txt, is one of these files. The ZIP returns 404 while the run is still in progress, so fetch it from a separate workflow that starts when the failed one completes:

on:
  workflow_run:
    workflows: ["Terraform"]  # the name of the workflow that fails
    types: [completed]

jobs:
  step-log:
    if: github.event.workflow_run.conclusion == 'failure'
    runs-on: ubuntu-latest
    permissions:
      actions: read
    steps:
      - env:
          GH_TOKEN: ${{ github.token }}
          RUN_ID: ${{ github.event.workflow_run.id }}
        run: |
          gh api "repos/$GITHUB_REPOSITORY/actions/runs/$RUN_ID/logs" > logs.zip
          unzip -p logs.zip "Terraform Format and Validate/4_*.txt"

If it has to happen inside the same run, like your step 6, the job log is the only source for now. Each run: and uses: step in it starts with a ##[group]Run ... line, so you can cut from the failed step's header to the next one.

[JoyForCode]

Thanks for independently reproducing this! That confirms what I was observing in my repository as well.

I hadn't considered extracting individual step logs from the workflow-run ZIP archive. That's a much better workaround than downloading the complete job logs and parsing them manually.

I'll try this approach in my workflow. Appreciate you taking the time to investigate and provide a reproducible example!

[Nezhinskiy]

Works now. I retested the mdn/browser-compat-data job from comment above (run 41591314160, job 125768456918, step 1) today, it gives 302 to the log. Also works for finished steps of running jobs.

More here: https://github.com/orgs/community/discussions/75518#discussioncomment-19562148