> ## Content Index
> Fetch the complete content index at: https://blog.harshkohli.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# GitHub Timeouts Hit Users Who Aren't Signed In
- URL: https://blog.harshkohli.com/github-timeouts-unauthenticated-users/
- Published: 2026-11-08T13:19:53.000Z
- Updated: 2026-11-08T13:19:53.000Z
- Description: GitHub reported timeouts for some people who aren't signed in. API requests were later mitigated. Check githubstatus.com and try signing in.
- Author: Harsh Kohli
- Tags: Tech News, Software

If a public GitHub page stalled on you this afternoon, or a release download timed out, or an anonymous API call came back with a 504, you weren't alone. GitHub opened an incident at 16:06 IST (10:36 UTC) after reports of timeouts, and later said the trouble was mainly hitting people who weren't signed in.

## What GitHub has said so far

The note on [GitHub Status](https://www.githubstatus.com/?ref=blog.harshkohli.com) is titled "Increase in timeouts for some unauthenticated users." [@githubstatus posted](https://x.com/githubstatus/status/2119378419909615820?ref=blog.harshkohli.com) at 10:36 UTC that it was investigating impacted performance on some services. At 11:16 UTC (16:46 IST) it [said the degraded performance was "primarily for unauthenticated users."](https://x.com/githubstatus/status/2119388544108020055?ref=blog.harshkohli.com) Four minutes later it flagged API Requests, and at 11:50 UTC (17:20 IST) it [said it had found a problematic component](https://x.com/githubstatus/status/2119397227495850367?ref=blog.harshkohli.com) and was working to redeploy it.

At 11:56 UTC (17:26 IST), GitHub [said the API Requests degradation had been mitigated](https://x.com/githubstatus/status/2119398617312116954?ref=blog.harshkohli.com) and that it was monitoring for stability. A later status-page update at 12:29 UTC (17:59 IST) widened that to: "The degradation has been mitigated. We are monitoring to ensure stability." The incident is still listed as unresolved and in monitoring, even though Git Operations, API Requests, Actions and the other named services are showing as Operational, and the banner reads "All Systems Operational."

GitHub has not named the component, given a count of people affected, or said what caused it. It also has not called this a DDoS, even though a few users guessed that on social media. That guess is still just a guess.

On the user side, people have described 504s and a pattern I keep seeing in replies: an anonymous curl of a release asset failed, then the same request worked after they signed in or added a token. I am treating those as anecdotes. They fit GitHub's wording, and they are still not a measurement from GitHub.

## Why it matters

A lot of everyday GitHub traffic is anonymous: opening a public repo without an account, a package manager grabbing a release tarball, a CI job downloading an asset without a token, a script hitting the API with no login. Those paths already get a tighter rate limit than signed-in traffic. When they also time out, the breakage shows up in places that look nothing like "I cannot load github.com."

And this was not GitHub's only messy day this week. There was a multi-service degradation early on November 6, an Actions incident on November 5, trouble with Actions, Pages and Git Operations on November 4, and slow Git-over-HTTPS on November 3\. I would not stitch those into one cause, and I would not tell a tired teammate they imagined the week.

## My take: what to do right now

1. **Check the status page before you rewrite anything.** Go to [githubstatus.com](https://www.githubstatus.com/?ref=blog.harshkohli.com). As of this writing the named services look green and GitHub says the degradation is mitigated, but the unauthenticated-timeouts incident is still in monitoring. Refresh it if things break.
2. **If a public page or anonymous download fails, try signing in.** People said logging in, or passing a personal access token, got them through when unsigned requests returned 504s. That matches GitHub's wording. Nobody on the status page told you to do it; it is just what worked for them.
3. **Do not paste that token into a script you will commit or share.** A token in an Action log, a gist or a chat snippet is a gift to whoever finds it. Keep it in an environment variable or secret store, and rotate it if leaked. I walked through that after the [Railway breach](https://blog.harshkohli.com/railway-breach-rotate-api-keys/), and it applies here too.
4. **Give failing jobs a minute instead of hammering retry.** A tight loop against a struggling endpoint makes things worse for everyone. Try once more, then wait and recheck.
5. **Leave signed-in git alone if it is working.** GitHub pointed at unauthenticated users first, then at API Requests, which it later said it had mitigated. If credentialed git or your logged-in browser is fine, leave it.

Skip grabbing a "mirror" of a release from a random repo because the official asset timed out. Wait, or use a token on the official URL.

My honest view: next to the rest of GitHub's week, this one looks smaller. I would still watch the status page for a bit, sign in when a public request fails, and pull any leftover token out of a script once things settle.