Activity

1. becco

   added

   feature

   on Oct 26, 2026
2. vistart commented on Oct 28, 2026

   

   vistart

   on Oct 28, 2026

   More actions

   I hit the same problem while building a CI tracker, and did some extra
   digging that may help narrow this down. Short version: the endpoint never
   gets as far as the 302 — it answers with a 404 before any Location is
   produced, and that 404 is not a "route not found" 404.

   Environment

   • rhosocial/python-activerecord (public), run 40632965464, job
     122633372679, step 3 ("Check out the repository")
   • fine-grained PAT that can read this repository's Actions; the same token
     gets 200/302 from the endpoints used as controls below
   • X-GitHub-Api-Version: 2026-03-10, Accept: application/vnd.github+json
   • 2026-10-28 ~07:15 UTC

   What the docs promise

   GET /repos/{owner}/{repo}/actions/jobs/{job_id}/steps/{step_number}/logs
   → 302 with a Location pointing at a plain-text log.

   What actually happens

   GET /repos/rhosocial/python-activerecord/actions/jobs/122633372679/steps/3/logs
   
   HTTP/2 404
   content-type: application/json; charset=utf-8
   x-github-api-version-selected: 2026-03-10
   x-github-request-id: 8DBC:12702D:B78CAD:11FA621:6AE1A342
   (no Location)
   
   {"message":"Not Found",
    "documentation_url":"https://docs.github.com/rest/actions/workflow-jobs#download-step-logs-for-a-workflow-run-job",
    "status":"404"}
   

   Control, same job and same token:

   GET /repos/rhosocial/python-activerecord/actions/jobs/122633372679/logs
   
   HTTP/2 302
   location: https://productionresultssa32.blob.core.windows.net/.../job-logs.txt?...
   

   So there is no redirect and no signed URL to test for expiry or permission
   problems — the failure happens before the redirect.

   Why this doesn't look like a typo / missing route

   Request	Status	documentation_url	version header
   .../jobs/{id}/steps/3/logs	404	operation-specific anchor	present
   .../jobs/{id}/bogus	404	generic https://docs.github.com/rest	absent
   .../jobs/{id}/steps/3 (no /logs)	404	generic	absent
   .../jobs/{id}/steps/3/logs/ (trailing slash)	404	generic	absent
   .../jobs/{id}/steps/three/logs	404	operation-specific anchor	present
   .../jobs/999999999999 (known route, missing job)	404	...#get-a-job-for-a-workflow-run	present

   Also:

   • OPTIONS .../jobs/{id}/steps/3/logs → 204, while
     OPTIONS .../jobs/{id}/bogus → 404.
   • HEAD behaves like GET (404).
   • A non-numeric step (three) still resolves to this operation, so the
     route is not validating step_number as an integer; it looks like a
     handler-level "no such step log", not a path mismatch.

   That combination — operation-specific 404, API-version header, OPTIONS
   204, exact path matching — is what a real endpoint returns when the
   resource is missing, not what an unknown path returns.

   Scope of the reproduction

   I could not find any combination that returns 302:

   • public repos: rhosocial/python-activerecord, actions/setup-python,
     microsoft/vscode, github/docs, vercel/next.js, rust-lang/rust,
     kubernetes/kubernetes, python/cpython, home-assistant/core
   • several private repositories in my organization (same result)
   • jobs in completed and in_progress state
   • step numbers 0–13, plus the non-contiguous sets the Jobs API returns
     (e.g. [1,2,3,4,5,6,10,11,12,13], [1,...,14,27,28])
   • with and without a token; 2026-03-10 and 2022-11-28; Accept set to
     application/vnd.github+json, application/json, and
     application/vnd.github.raw

   All 404.

   For contrast: the job-level endpoint is fine

   GET .../jobs/{id}/logs → 302 → text/plain (288,675 bytes for a 10-step
   job). The blob URL works without Authorization; forwarding the GitHub
   token gives 401 InvalidAuthenticationInfo from Azure. That part of the
   docs matches reality.

   Why this matters

   I'm building a CI tracker; downloading the entire job log just to display
   one step is expensive (some jobs are 20k+ lines, and this one is ~289 KB for
   10 steps). The web UI's per-step URL
   (/commit/{sha}/checks/{job_id}/logs/{n}) is session-auth only — the same
   limitation described in cli/cli#11157. This endpoint is exactly what's
   needed to avoid that.

   Questions

   The section does not appear in the 2026-09-27 Wayback snapshot of the page
   but does now, so this may be docs merged ahead of the rollout.

   • Is the endpoint deployed? If not, could the docs be marked as "not yet
     available" (or removed) until it is?
   • If it is deployed, what are the missing conditions? (org/repo plan,
     runner type, region, log-storage backend, token type?)
   • Is a per-step log guaranteed to exist for every completed job/step, or
     only for a subset?

   Thanks!