Release asset downloads (/releases/download/) returning 504 from GitHub-hosted Actions runners since ~08:45 UTC 2026-11-08

[lev-levin-lumia]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Actions Runner

Discussion Details

Since about 08:45 UTC today, downloading release assets via https://github.com/<owner>/<repo>/releases/download/<tag>/<asset> from GitHub-hosted runners (ubuntu26 image 20261101.186) fails with HTTP 504, about 11s per attempt. Retries mostly fail too.

Example: golangci/golangci-lint-action@v9 downloading https://github.com/golangci/golangci-lint/releases/download/v2.11.4/golangci-lint-2.11.4-linux-amd64.tar.gz failed on 4 consecutive attempts between 08:50 and 09:12 UTC:

Downloading binary https://github.com/golangci/golangci-lint/releases/download/v2.11.4/golangci-lint-2.11.4-linux-amd64.tar.gz ...
Unexpected HTTP response: 504
Unexpected HTTP response: 504
##[error]Failed to run: Error: Unexpected HTTP response: 504, Error: Unexpected HTTP response: 504

The same URL downloads fine from outside Actions. Reports suggest the API asset endpoint is unaffected.

It's widespread: ~20 public repos opened issues in a ~25 min window for the same failure on different tools (Bun, Deno, CPython, sccache, gitleaks, cmake, …), e.g.:

• Error: Unexpected HTTP response: 504 jwlawson/actions-setup-cmake#102
• master ci red: github.com release downloads return 504 (victoria-logs, golangci-lint) elee1766/jobshop#1040
• infra: GitHub release web-endpoint downloads intermittently 504 (API asset endpoint unaffected) tamld/g8s#838

githubstatus.com shows all systems operational.

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

[RobertWi]

Same here, but NOT limited to Actions: it fails from our own network too
(self-hosted GitLab runners and plain curl on two hosts in NL, IPv4), routed
through the Frankfurt edge. Since about 10:00 CET, still failing 11:15 CET.

It breaks Terraform/OpenTofu provider installs, since the registry hands out
github.com release URLs for providers and their SHA256SUMS:

curl -sI https://github.com/gitlabhq/terraform-provider-gitlab/releases/download/v17.11.0/terraform-provider-gitlab_17.11.0_SHA256SUMS
HTTP/2 504
x-github-request-id: B82C:30B5AF:BB71D4B:10B49BE3:6AF03FCB
x-github-edge-region: fra

github.com itself answers 200; the 504 is specific to /releases/download/.

[michawai]

Same here - trying to access public repos in github.com and it fails with 504:
504 Gateway Time-out
The server didn't respond in time.

[juceda]

It’s been failing for me too since this morning—accessing from Spain. I can’t view any repo via HTTP; I keep getting a 504 error.

I’ve tried accessing from various machines I have in several PoPs (USA/North Virginia, Ireland, Paris, etc.) with the same result :(

[ferdimsu]

Same here

[mosh-gold]

same here

[mosh-gold]

[ferdimsu]

no

[mosh-gold]

probably got routed to a different server for a split second

[tomer-epstein]

Same

curl --fail -s -S -L --retry 3 --retry-all-errors https://github.com/mikefarah/yq/releases/download/v4.27.3/yq_linux_amd64 -o ./yq
curl: (22) The requested URL returned error: 504
curl: (22) The requested URL returned error: 504
curl: (22) The requested URL returned error: 504
curl: (22) The requested URL returned error: 504

[elivaknink]

same issue here. is anyone looking into it? The status page doesn't show any issues

[undo-git-pull]

This is impacting homebrew installs

[SamadKhafi]

Impacting AUR (Arch User Repository) installs aswell.

[Fuma2514]

What this is

A CDN/edge incident on the release-download path, not an Actions problem. The last reports here put it at the Frankfurt edge (and others across Europe), which is why githubstatus.com can still read all-green for a while: the status page aggregates broad availability, and a degraded subset of edge PoPs that still serves the dashboard and API can 504 on the /releases/download/ redirect chain (it goes github.com → objects.githubusercontent.com) while API traffic works, exactly matching the "API asset endpoint is unaffected" observation.

Workarounds that keep CI green while it lasts

1. Route through the API asset endpoint, which uses a different serving path:

   - run: |
       curl -sSL -H "Accept: application/octet-stream"          -o golangci-lint.tar.gz          https://api.github.com/repos/golangci/golangci-lint/releases/assets/$(            curl -sS https://api.github.com/repos/golangci/golangci-lint/releases/tags/v2.11.4 |            jq -r '.assets[] | select(.name | test("linux-amd64.tar.gz$")) | .id')

   (no auth needed for public repos; add ${{ secrets.GITHUB_TOKEN }} as a bearer header to avoid API rate limiting on shared runner IPs).

2. Retry with backoff + cache, so a single edge blip doesn't kill the job:

   - uses: actions/cache@v4
     with:
       path: ~/.cache/tools/golangci-lint
       key: golangci-lint-v2.11.4
   - run: |
       for i in 1 2 3 4 5; do
         curl -fsSL --retry 3 --retry-all-errors -o /tmp/gcl.tgz "$URL" && break
         sleep $((i * 15))
       done

3. Pin a mirror: since the 504 only affects github.com/<owner>/<repo>/releases/download/..., downloading the same artifact from an alternate host (a separate mirror repo's release, or a package registry like go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.11.4, which pulls via the module proxy, not the release CDN) bypasses the failing path entirely.

How to confirm it's fixed

Watch the 504 rate from a runner: curl -o /dev/null -w '%{http_code} %{time_total}s ' -L "$URL" — when it returns 200 in the normal ~1-2s window rather than the ~11s timeout, the edge has recovered. Worth updating the top post with the recovery time so others searching this thread get the window of affected runs; also note that the Actions status page is the right place to watch, since /releases/download degradation is reported there when it crosses the incident threshold.

[jh3141]

"The last reports here put it at the Frankfurt edge (and others across Europe)" — there's a report on reddit about it affecting India also.

[MikeSchulze]

same here, it blocks me to work

[undo-git-pull]

watching it with:

while :; do
  if curl --fail -sS -L --retry 3 --retry-all-errors -r 0-0 -o /dev/null https://github.com/mikefarah/yq/releases/download/v4.27.3/yq_linux_amd64; then
    echo "$(date +%T) working"; break
  fi
  echo "$(date +%T) still failing"; sleep 300
done

[boutebel]

Since at least 08:57 UTC on 2026-11-08, downloading release assets from
github.com returns HTTP 504 after ~11 seconds, from several networks
(Azure DevOps Microsoft-hosted agents and an independent host).
Other GitHub endpoints (raw.githubusercontent.com) respond normally.

Examples:

• https://github.com/amacneil/dbmate/releases/download/v2.36.0/dbmate-linux-amd64
• https://github.com/gitleaks/gitleaks/releases/download/v8.30.0/gitleaks_8.30.0_linux_x64.tar.gz

Response headers (09:54:28 UTC):
HTTP/1.1 504 Gateway Time-out
X-Github-Edge-Region: iad
X-Github-Request-Id: 8009:966FA:1531A20:1B11F93:6AF046B2

Still failing at 09:54 UTC. githubstatus.com shows no incident.
Impact: all our CI pipelines are blocked.

[thejoester]

Also having the issue, both from my home network and my oracle cloud server. It does seem to randomly work once in a while but goes right back to failing again.

me@myserver:~$ curl -sIL https://github.com/foundryvtt/pf2e/releases/download/pf2e-8.7.0/system.zip | head -20
HTTP/2 504
content-length: 92
cache-control: no-cache
content-type: text/html
date: Sun, 08 Nov 2026 10:00:43 GMT
x-github-request-id: 9ADA:B5A4B:15A7B4B:1BA1D7B:6AF04840
x-github-edge-region: iad
x-frame-options: DENY
strict-transport-security: max-age=31536000; includeSubDomains; preload

me@myserver:~$ until curl -sI https://github.com/foundryvtt/pf2e/releases/download/pf2e-8.7.0/system.zip | grep -qE 'HTTP/2 (200|302)'; do echo "still 504 $(date +%T)"; sleep 30; done; echo "UP — install now"
still 504 10:04:39
still 504 10:05:20
still 504 10:05:50
still 504 10:06:32
still 504 10:07:02
still 504 10:07:43
still 504 10:08:24
still 504 10:08:55

I am gonna increase the sleep to 300, I am sure all of us pinging it constantly is not great :P

[alfianakbar]

I also had this issue. But it seems working now.

[Gormathor]

I can confirm this issue is not limited to GitHub Actions runners. I'm experiencing the same HTTP 504 failures when downloading release assets directly from Windows 11 in the Netherlands.

I performed reproducible tests on November 8, 2026, using Windows PowerShell and curl.exe.

Control tests (11:03–11:04 CET):

• https://github.com/ — HTTP 200 (3/3 attempts)
• https://api.github.com/ — HTTP 200 (3/3 attempts)
• GitHub Releases download — HTTP 504 (3/3 attempts)

The homepage and failing release requests both reached 140.82.121.3, indicating that general connectivity to GitHub is working.

Affected repositories:

1. LizardByte/libvirtualhid

https://github.com/LizardByte/libvirtualhid/releases/download/v2026.914.1218.10/libvirtualhid-Windows-AMD64-driver-installer.msi

• HTTP status: 504 Gateway Time-out
• Timestamp: 2026-11-08 10:04:09 UTC
• Edge region: fra
• Request ID: D547:2F0A0C:C5608E2:1190FE26:6AF04952

2. microsoft/PowerToys

https://github.com/microsoft/PowerToys/releases/download/v0.102.3101/PowerToysSetup-0.102.3101.0-x64.exe

• HTTP status: 504 Gateway Time-out
• Timestamp: 2026-11-08 10:04:31 UTC
• Edge region: fra
• Request ID: EEFA:294D71:BB4E7F3:10B995E9:6AF04973

Additional findings:

• Both release requests returned HTTP 504 before any redirect to the asset CDN.
• The first LizardByte request took 11.325 seconds to return HTTP 504.
• Subsequent attempts returned HTTP 504 in approximately 0.13–0.15 seconds.
• The issue is reproducible on Odido fiber, Odido mobile data, and with Proton VPN enabled and disabled.
• Multiple package updates through UniGetUI are also failing.

This suggests an issue specifically affecting GitHub's /releases/download/ endpoints or their upstream dependencies, rather than general GitHub connectivity.

The request IDs above should hopefully help GitHub engineers trace the failures.

Adding these findings to confirm the broader impact outside GitHub Actions.

[mt190502]

Same issue here:

  Error: Error locating chart
  
    with helm_release.this,
    on helm.tf line 22, in resource "helm_release" "this":
    22: resource "helm_release" "this" {
  
  Unable to locate chart kube-prometheus-stack: failed to fetch
  https://github.com/prometheus-community/helm-charts/releases/download/kube-prometheus-stack-93.1.0/kube-prometheus-stack-93.1.0.tgz
  : 504 Gateway Timeout
  
  exit status 1

[cjnova]

Same here

[mcitem]

 Downloading https://github.com/tauri-apps/binary-releases/releases/download/nsis-3.13/nsis-3.13.zip
failed to bundle project: `http status: 504`
       Error failed to bundle project: `http status: 504`
[ELIFECYCLE] Command failed with exit code 1.

[Crudzz]

Same here

[lidor-kela]

same

[boutebel]

Updates :
curl.exe -sS -o NUL -D - https://github.com/amacneil/dbmate/releases/download/v2.36.0/dbmate-linux-amd64 | Select-String "HTTP/|X-Github"

HTTP/1.1 302 Found
Vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With, X-GitHub-Client-Version,
Sec-Fetch-Site,Accept-Encoding, Accept, X-Requested-With
X-GitHub-Request-Id: 1264:61EC4:5630A8:E2998B:6AF0508A
x-github-edge-region: switzerlandnorth

[aslze]

I noticed this when trying to update an app with winget, but then I tried to download it directly with the web browser and it worked. It turns out I was already logged-in to github when it worked. I then tried in a private window (logged-out) and it failed with 504.

So github seems to be responding differently to authenticated and non-authenticated requests.

[ferdimsu]

observed the same thing

[boutebel]

should be okay now

[BirdmanRS]

Negative...

[jh3141]

Working for me directly from UK and from google colab, not sure what location that comes from.

[cjnova]

not working

[BirdmanRS]

GitHub reporting the issue:
https://www.githubstatus.com/incidents/pyynvrm1vskw

[cory-hireup]

Working for me from Spain

[Tauris]

Same failure for /raw/ file URLs, from all regions, details in #212414.

[benfurkanbaris]

On a GitHub-hosted Ubuntu runner, downloading the pinned Supabase CLI 2.121.0 Linux amd64 archive returned HTTP 504 around 08:44, 08:54, and 10:07 UTC on November 8, 2026. The same archive had downloaded and passed SHA-256 verification in the same workflow before 08:33 UTC. The digest published for the release asset matches the checksum pinned in the workflow.

The public release asset is supabase_2.121.0_linux_amd64.tar.gz from Supabase CLI 2.121.0. Could you check whether there is a delivery problem affecting this file on GitHub Actions runners, or a recovery update specific to this download?

[Morodar]

According to https://www.githubstatus.com/incidents/pyynvrm1vskw:

Update
The degradation affecting API Requests has been mitigated. We are monitoring to ensure stability.
Posted 7 minutes ago. Nov 08, 2026 - 11:56 UTC

[thejoester]

Still seeing failures.

[juceda]

Still seeing failures.

"mitigated" does not mean "resolved" ;)

[tomer-epstein]

status has been changed to Resolved 1 min ago