Release asset downloads (/releases/download/...) returning 504 Gateway Time-out across all repos

[dopaemon]

Summary

Since roughly 2026-11-08 09:45 UTC, every request to https://github.com/<owner>/<repo>/releases/download/<tag>/<asset> returns 504 Gateway Time-out with a 92-byte HTML error body, instead of redirecting to objects.githubusercontent.com.

This is not repo-specific: it reproduces on unrelated public repositories. raw.githubusercontent.com, codeload.github.com, the REST API and the website itself are all fine, so it looks isolated to the release-asset download redirect path.

githubstatus.com still reports All Systems Operational.

Reproduce

$ curl -sL -o /dev/null -w "status=%{http_code}\n" \
    https://github.com/cli/cli/releases/download/v2.62.0/gh_2.62.0_checksums.txt
status=504

$ curl -sL -o /dev/null -w "status=%{http_code}\n" \
    https://github.com/git-lfs/git-lfs/releases/download/v3.5.1/hashes.asc
status=504

$ curl -sL -o /dev/null -w "status=%{http_code}\n" \
    https://github.com/JetBrains/kotlin/releases/download/v2.2.21/kotlin-compiler-embeddable-2.2.21.jar
status=504

$ curl -sL -o /dev/null -w "status=%{http_code}\n" \
    https://github.com/simolus3/sqlite3.dart/releases/download/sqlite3-3.5.2/libsqlite3.x64.linux.so
status=504

The response body is always the same 92 bytes:

<html><body><h1>504 Gateway Time-out</h1>
The server didn't respond in time.
</body></html>

What still works from the same machine, same minute:

Endpoint	Result
https://github.com/	200
https://raw.githubusercontent.com/cli/cli/trunk/README.md	200
https://codeload.github.com/cli/cli/tar.gz/refs/tags/v2.62.0	200
https://api.github.com/repos/.../releases/assets/<id> (Accept: application/octet-stream)	200, correct bytes
https://github.com/*/releases/download/*	504 (every repo tried)

No Location: header is returned on the 504 — the request dies at github.com before the redirect to objects.githubusercontent.com is issued. Each attempt takes ~11.5 s before failing.

The assets themselves are intact — fetched through the REST API, the very file that "failed its checksum" in CI hashes exactly as expected:

$ curl -sL -H "Accept: application/octet-stream" -o api.so \
    https://api.github.com/repos/simolus3/sqlite3.dart/releases/assets/521380082
$ shasum -a 256 api.so
b17729184e5a2818055ecbddd5ed6642521bfe6e56aafa472330e483c0e2e0d2  api.so   # expected hash, 1801592 bytes

So this is purely the github.com/.../releases/download/... entry point timing out.

Request IDs

C52F:16A74A:2D136FF:465A371:6AF04C9F
C59C:216523:2D2A366:4686741:6AF04CC8
C5A7:29E0A8:2D2A76D:4677226:6AF04CC8
C5A8:2A51F8:2D39651:4693C70:6AF04CC8
C5DE:34F629:2D2577E:466871F:6AF04CE1

x-github-edge-region: southeastasia

Impact on GitHub-hosted Actions runners

The same failure happens on ubuntu-latest and macos-latest runners, so it is not limited to one network. Any build step that pulls a release asset breaks:

• Gradle / Kotlin — Could not GET 'https://github.com/JetBrains/kotlin/releases/download/v2.2.21/kotlin-compiler-embeddable-2.2.21.jar'. Received status code 504 from server: Gateway Time-out

• Dart / Flutter native assets — the package:sqlite3 build hook downloads prebuilt binaries from a GitHub release. It streams the response body without checking the HTTP status, so the 504 HTML page gets hashed and surfaces as a confusing checksum error:

  Bad state: Hash of downloaded file libsqlite3.x64.linux.so is
  bef140a1a96994029153dca8c00b1750b9a5a764fb9db2dc68d7bb40e8a29e8a,
  expected b17729184e5a2818055ecbddd5ed6642521bfe6e56aafa472330e483c0e2e0d2.
  

  bef140a1a96994029153dca8c00b1750b9a5a764fb9db2dc68d7bb40e8a29e8a is just sha256 of that 92-byte 504 page — which is why the same hash is reported for completely different artifacts (libsqlite3.x64.linux.so on Linux and libsqlite3.arm64.ios.dylib on macOS). Worth flagging for anyone debugging a "hash mismatch" today: it is almost certainly this outage, not a tampered or re-uploaded artifact.

Ask

• Is this a known incident? If so, could the status page reflect it — "All Systems Operational" sends everyone hunting for a checksum/supply-chain problem in their own toolchain.
• Anyone else seeing it, and from which edge regions? Narrowing that down would help.

Workaround that does work right now, if you control the downloader: resolve the asset id and fetch it through the REST API instead —

id=$(gh api repos/OWNER/REPO/releases/tags/TAG --jq '.assets[] | select(.name=="FILE") | .id')
curl -sL -H "Accept: application/octet-stream" -o FILE \
  "https://api.github.com/repos/OWNER/REPO/releases/assets/$id"

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

[elijulian]

Same failure from a different edge, x-github-edge-region: israelcentral, and from AWS CodeBuild GitHub Actions runners in us-east. Not limited to one network.

Unauthenticated GET of these URLs returned 504 Gateway Time-out with the same 92-byte HTML body (The server didn't respond in time.). No Location header. Failures took about 11s, or sometimes under 100ms.

• https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.13%2B9/OpenJDK21U-jdk_x64_linux_hotspot_21.0.13_9.tar.gz
• https://github.com/sigstore/cosign/releases/download/v2.5.2/cosign-linux-amd64

Request IDs from 10:12 UTC:

9383:0856:79F648:DC200C:6AF04B17
D353:2E579:7A0B42:DC748D:6AF04B17

Timeline from here: the Temurin URL succeeded at 08:22 and 08:43 UTC, then started failing around 08:52 UTC. Still 504 at 10:22 UTC. Both URLs were 302 again at 10:34 UTC, so it is flapping rather than fully down.

actions/setup-java (Temurin) and sigstore/cosign-installer both failed on this in Actions. raw.githubusercontent.com, source archives, and api.github.com asset downloads with Accept: application/octet-stream kept working. githubstatus.com still says all systems operational.

[lzdelara]

Confirming this from our side, still happening on 2026-11-09.

• What fails: tofu init in GitHub Actions can't install grafana/grafana v4.53.0 (Error while installing grafana/grafana v4.53.0: github.com: GET …/terraform-provider-grafana_4.53.0_linux_amd64.zip … giving up after 3 attempt(s)). Every OpenTofu plan that needs this provider has failed since about 05:36 UTC; the last success was 04:39 UTC.
• Reproduced outside Actions: a plain curl -L from an AWS EC2 host in ap-northeast-1 gets HTTP 504 from https://github.com/grafana/terraform-provider-grafana/releases/download/v4.53.0/terraform-provider-grafana_4.53.0_linux_amd64.zip, repeatedly (05:58–06:15 UTC).
• Not every asset: in the same minutes, the same repo's v4.52.0 zip and other repos' release files downloaded fine (200).
• Workaround that works: the REST asset endpoint returns the full file. GET /repos/grafana/terraform-provider-grafana/releases/assets/686136306 with Accept: application/octet-stream and a token returned 200 with all 30,405,059 bytes, while the /releases/download/ URL returned 504.
• githubstatus.com showed "All Systems Operational" the whole time.