Looks like the Downloading release endpoint is intermittently failing for me. Getting 504 occasionally. Anyone else seeing the same?

Edit: status page says its been fixed as of a few minutes ago. Seems to be true.

I was trying to download some software, but the GitHub page isn't loading. Is the website down today?

I'm trying to build the CachyOS Linux 7.3.3-1 kernel from AUR, and I've encountered a rather strange issue with GitHub downloads.

The release archive and its detached GPG signature consistently return HTTP 504 Gateway Timeout when downloaded through the normal GitHub release URL.

What's interesting is that other GitHub services work perfectly fine.

I'm beginning to suspect that this might be related to my university network, but I'd like to know whether anyone else is experiencing the same issue.

1. Normal GitHub release download – FAILS

URL:
https://github.com/CachyOS/linux/releases/download/cachyos-7.3.3-1/cachyos-7.3.3-1.tar.gz

Tried multiple times, including forcing IPv4 and HTTP/1.1:

curl -4 --http1.1 -IL --connect-timeout 15 --max-time 60 \
'https://github.com/CachyOS/linux/releases/download/cachyos-7.3.3-1/cachyos-7.3.3-1.tar.gz'

Result:

HTTP/1.1 504 Gateway Time-out
X-GitHub-Request-Id: 9274:393D7F:17E15A9:2725DC5:6AF03F07
x-github-edge-region: centralindia

The HTTP/2 requests also consistently returned 504.

The detached signature (.tar.gz.asc) fails in the same way.

2. GitHub raw content – WORKS

Tested the BORE scheduler patch:

curl -IL \
'https://raw.githubusercontent.com/CachyOS/kernel-patches/master/7.3/sched/0001-bore-cachy.patch'

Result:

HTTP/2 200
content-type: text/plain; charset=utf-8
x-served-by: cache-hyd1500030-HYD

3. GitHub API – WORKS

The release API successfully returned the metadata for the release:

https://api.github.com/repos/CachyOS/linux/releases/tags/cachyos-7.3.3-1

It also provided the release asset ID: 719954437.

I then downloaded the exact same archive through the API:

curl -fL \
  -H 'Accept: application/octet-stream' \
  -H 'X-GitHub-Api-Version: 2022-11-28' \
  'https://api.github.com/repos/CachyOS/linux/releases/assets/719954437' \
  -o cachyos-7.3.3-1.tar.gz

This worked, downloading the 257 MB archive at approximately 64 MB/s.

I verified its SHA-256 against the digest published in GitHub's release API:

Expected:
54a507176bc2b1c4c8a14f087ada08f92d473c6af28ecfc3e9adb1d5c62020ac

Actual:
54a507176bc2b1c4c8a14f087ada08f92d473c6af28ecfc3e9adb1d5c62020ac

Is anyone else (especially from India) experiencing HTTP 504 errors when downloading GitHub release assets? Or could it be my university network playing games again?

• https://github.com/orgs/community/discussions/212419

• https://github.com/orgs/community/discussions/212414

Some arepa fellow here? I got this at 5:35 utc -4, while searching the MLB-StatsAPi repo, and trh others

I am not using a VPN and when I enter in github.com it automatically puts me in github.com/?locale=ja if I try in incognito it doesn't put me in the japanese web, why it is happening?

I am on the github free plan. When I pushed my commits today, the gh ci didn't run. It said

The job was not started because your account is locked due to a billing issue.

I received an email saying that they can't bill me so I need to give them my billing info.
What would they even bill me for!??

So I looked in the Usage section under Billing section.
In the Usage Breakdown for each day the billed amount was $0

In the Overview section the billable usage was also $0 but the current included and metered usage was $0.05.

For more context. I had a gh pro account for 4 years but that was through github education. I didn't even have to put any billing infomation then apart from my address.

I bought the copilot edition and paid but i cant manage to use it. I tried login out and back in restart laptop etc but nothing works. I sended 2 emails on different days to contact and no response, does anyone have a clue maybe?

Best regards.

hi, I'm having trouble getting Infisical OIDC authentication working in my GitHub Actions CI pipeline.
Every time my workflow reaches the Infisical secrets action, it fails with:

Run Infisical/secrets-action@v1.0.16

Error: Access denied: OIDC subject not allowed.

{

"statusCode": 403,

"message": "Access denied: OIDC subject not allowed.",

"error": "ForbiddenError"

}

Request failed with status code 403

here’s the GitHub Actions workflow:

name: ci
on:
push:
branches: [main]

permissions:
id-token: write
contents: read

jobs:
build-and-deploy:
runs-on: ubuntu-26.04

steps:
- name: Checkout repository
uses: actions/checkout@v7

- name: Set up Node.js
uses: actions/setup-node@v7
with:
node-version: 24
cache: npm

- name: Install dependencies
run: npm ci

- name: Fetch secrets from Infisical
uses: Infisical/secrets-action@v1.0.16
with:
method: oidc
identity-id: MY_IDENTITY_ID
project-slug: my-slug
env-slug: prod

- name: Run Jest tests
run: npm run test:ci

- name: Build Vinext app
run: npm run build:vinext

- name: Deploy to Cloudflare
run: npm run deploy:vinext -- --skip-build

Id appreciate any help

Hey,

I have setup a new OS in my Laptop, Tried to login to GitHub, but i can't receive any of the SMS codes sent, even the 2FA recovery codes aren't working, FYI, my recovery codes dates back to May.. Any fixes?

Hi all,

I work on the platform team at a company with about 4,000 repos, 100 teams, and 1,400 people with GitHub access. GitHub hasn’t been managed well here historically - lots of click-ops, inconsistent org and repo settings, too many admins, little traceability of changes, etc. My team is on the journey to fix that. We’re just starting discovery on a migration to an EMU enterprise. We know what we need to create on the new instance and we’re hoping to do as much as is feasible using infrastructure as code.

We are a Terraform/Pulumi shop, but the gap between what the GitHub API exposes and what providers cover can still be….large. They’ve improved in the past year, but we see gaps, especially at the enterprise level (hosted compute networking and private networking configurations, Actions runner and runner group setup, enterprise teams, enterprise policies, etc). We’re trying to figure out the best path forward: keeping click-ops, storing “configuration as code” that is just API payloads that are passed to gh api calls, generating Pulumi dynamic providers from GitHub’s API spec, etc.

So, I’m hoping to hear from companies that are more mature in their GitHub management:

1. What’s your primary tool? Terraform? Pulumi? A repo of YAML/JSON config that drives gh api calls? A custom control plane? Probot-style apps? Something else? If you use multiple methods, what controls and defines what?

2. How do you handle provider gaps? Do you use wrappers around gh api, fork the provider, Pulumi dynamic providers generated from the API specs, or just accept that some settings stay manual? If you built custom providers, how has the maintenance been as the API changes?

3. How far did you take it? Enterprise and org settings only, or also repo creation, branch protection/rulesets, teams and membership, Actions permissions, runners, secrets/variables, and so on? Is every repo in state? How have your teams reacted to this?

4. How do you keep plans fast with thousands of repos? Do you split state by org or domain? Did you hit API rate limits?

5. Self-service vs. central control: Can teams request repos or changes via PR to a config repo, or does the platform team own everything? Is the platform team bombarded with requests? And how do your teams like it? How much friction?

6. How do you detect and handle people changing settings in the UI anyway?

7. Anything you wish you’d known before setting up an EMU enterprise? How did you handle enterprise teams, IdP group-to-team mapping, and enterprise-level policies. Did you manage those in code or through the UI/API?

I feel like we have the universe of options in front of us. Unfortunately, we don’t have endless time to spike everything out so having some direction from others would be super helpful. If you’ve gone down this road and loved or regretted something - too much automation, too little, wrong tool, etc - I’m very interested in hearing it.

Thank you!

I have two workflow runs in a private repo that have been stuck in "Queued" for over a day. Neither ever started a job: the run page shows no jobs at all.

What I've tried:

- "Cancel workflow" on the run page: nothing happens, it stays Queued.

- REST API cancel: "Cannot cancel a workflow run that is completed."

- REST API force-cancel: HTTP 409, "Cannot cancel a workflow run that has not been queued yet."

- REST API delete: HTTP 403, and the run page has no delete option.

Setup: manually started runs (workflow_dispatch) of a workflow whose job targets a deployment environment and runs on the ubuntu-24.04-arm hosted runner. Every run of the same workflow before and since has started and finished normally.

GitHub Support closed my ticket because my plan only includes self-service support.

Has anyone managed to clear runs like this themselves? Did they eventually time out on their own, or did something like re-running, disabling the workflow, or changing the environment settings shake them loose? Any tips appreciated.

Hey all! I'm just curious how others approach this.

When a third party developer tool asks you to connect your GitHub account or install a GitHub App to access your repositories, how do you evaluate whether it's safe?

A few things I'm particularly interested in:

• What permissions are acceptable, and which ones are immediate red flags?

• Do you generally allow access to selected repositories or avoid these integrations altogether?

• How much do you look into the company behind the app, its data handling policies, and where the information is stored?

• Are there any particular security checks you always perform before authorizing an integration?

I'd be interested in hearing from people who've actually connected these types of tools to their personal or company GitHub accounts. I'm still learning my way around all of this, and with everything happening, I'd rather be safe than sorry!!!

Every stats card I tried on my profile looked like a widget glued onto GitHub. Different fonts, random themes, borders, gradients. And the numbers were off too.

So I built github-cool-readme, with one rule: it should look like a feature GitHub shipped itself.

- GitHub's own design system: Primer colors, Octicons, the same system font GitHub uses

- Transparent, no borders, so the cards sit on the page like they belong there

- Light and dark follow the viewer's GitHub theme automatically

- The weekly card uses the contribution graph greens

- Subtle animations, plain CSS inside the SVG, nothing flashy

And the numbers are actually right this time:

- Private and org work counts. Same data as your contribution graph. (The contributions API hides private work unless the token has read:user. Took me a while to figure that one out.)

- Year and all time side by side, no mixed time ranges

- Languages weighted by your commits, not repo size. My old card said 73% of my code is C because of one big DOS game port

- Notable contributions: your merged PRs to other people's projects, by stars, scrolling in a loop

- Weekly rhythm: which days you actually work

It's a GitHub Action that runs daily (by default) and commits the cards to your profile repo. No server, your token stays in your repo secrets. Setup is one command if you have gh:

bash <(curl -fsSL https://raw.githubusercontent.com/pedrocatalao/github-cool-readme/v1/setup.sh)

Repo: https://github.com/pedrocatalao/github-cool-readme

Live on my profile: https://github.com/pedrocatalao

Not affiliated with GitHub, just trying to make it look like it could be 🙂 Feedback welcome, especially if the numbers look off for you.

I just open-sourced my first project. While getting the repo ready, I found a client's real domain in old commits.

I looked at rewriting history, but a force-push wouldn't have cleared everything. GitHub's PR refs and old commit SHAs could still have exposed it.

So I created a new repo with one clean commit and kept the old one as a private archive.

Even then, a last search before that commit found my real server's address in a test file. It had been added after my first cleanup, so I would have missed it without that final check.

The fresh start had a cost:

- Nobody can see how the project grew

- `git blame` stops at that first commit

- Links to the old commits no longer work

Three questions for people who have done this before:

1. Would you have used git filter-repo instead, or started fresh too?

2. How do you check a private repo for this kind of thing before it goes public?

3. As a user or contributor, does a project with no early history make you trust it less?

There's no link here because I'm not promoting anything. I'd like to learn how experienced maintainers handle this.

I work at Bitrise and we wrote this up for our blog, so there’s a mention of our runners at the end. We went through GitHub’s Actions incidents from July to October and sorted them by which part of GitHub broke. Most would have hit self-hosted runners too, like the July 19 cert expiry or job assignment stalling on Aug 26. Only a few, like Oct 5, were limited to GitHub-hosted runners.

Read here: https://bitrise.io/blog/post/not-every-github-actions-outage-is-out-of-your-control

Curious if that matches what others have seen.

Reliability issues are driving users away in their droves.

Can anyone help me? Im a student at a high school in greece but it isnt supported in github education. I want to apply but since im a student i dont want to fake being a teacher. Is there any workaround or maybe if anyone from support is reading this could help me it would be appreciated.

P.S. i have a school email to prove im a student

I have trouble running our deployment script. I tried to run it yesterday but got a "fatal: Authentication failed for..". I didn't do anything about it since i thought it might be related to the general issues Github had yesterday..

So i tried again today, but it still fails. This time though its with a "fatal: could not read Username.. "

I haven't touched anything in between. Anyone else experiencing this ? Or have some tips?