GitHub Outage Map

Community Discussion

Tips? Frustrations? Share them here. Useful comments include a description of the problem, city and postal code.

Beware of "support numbers" or "recovery" accounts that might be posted below. Make sure to report and downvote those comments. Avoid posting your personal information.

GitHub Issues Reports

Latest outage, problems and issue reports in social media:

• 
  vjeux ✪ (@Vjeux) reported 1 second ago

  We've got an interesting problem. @aarongarciah mentioned that accessibility of Astryx wasn't as good as Base UI. So @thedjpetersen and @pockyonastick got Fable on the job and it generated 50 PRs. But now GitHub actions (CI) are completely backed up... Brand new world!

• 
  SeaTicket (@SeaTicketAI) reported 3 minutes ago

  @Nightzstalker SeaTicket continuously syncs connected sources into one workspace. AI agents analyze issues across GitHub, Emails, Discourse, docs, Notion, Seafile libraries, and more, then suggest actions for your team to review.

• 
  Wesley / donnaken15 (@ptr__WESLEY) reported 3 minutes ago

  @github fix online code searching

• 
  Rambone (@vinrambone) reported 4 minutes ago

  @sudoingX My blank github days are spent deep in a rabbit hole of code im not ready to push bc its too broken But i dont want to *** restore.

• 
  BowTiedCrocodile | Agentic Coding (@BowTiedCrocodil) reported 5 minutes ago

  Incredible When GitHub goes down just use the CD they sent you

• 
  Jess Daniel (@jess_daniel10) reported 5 minutes ago

  @neetcode1 I was testing something with a local server and I told 5.5 to test with the GitHub MCP and it downloaded a local GitHub mcp and ran it locally… even though GitHub hosts it already.

• 
  Matt Teixeira (@matt_teeixeira) reported 6 minutes ago

  Is there nothing else to do at GitHub? Like availability issues?

• 
  Joey Kudish (@jkudish) reported 10 minutes ago

  Cool, but could we fix other GitHub problems first?

• 
  GoCocoaAI (@GoCocoaAI) reported 12 minutes ago

  The epoll subsystem has been load-bearing infrastructure since Linux 2.5.44. A single April 2023 commit buried two distinct race conditions inside roughly 2,500 lines of code. Anthropic's Mythos AI found one of them. A human researcher found the other. The one Mythos missed is CVE-2026-46242 — "Bad Epoll" — and it comes with a working PoC, 99% exploit reliability, and a path from Chrome's renderer sandbox to kernel code execution on Android. The bug class is a race-condition use-after-free in the kernel's epoll subsystem, kernels v6.4 through approximately v6.12.67. Close two epoll objects simultaneously and one close path frees a kernel object while the other is still writing into it. The exploit widens the ~6-instruction race window via a timer interrupt technique, lands an 8-byte UAF write, pivots to a dangling struct file backed by a pipe, leaks arbitrary kernel memory through /proc/self/fdinfo, hijacks control flow, and drops a ROP chain to root. The retry loop never panics the kernel. That's what makes 99% credible. The PoC has been public on GitHub since June 24 — nine days ago, 192 stars, 19 forks. There is no kill-switch. Epoll is a core kernel primitive. It cannot be disabled or unloaded. Patch or stay exposed. The Chrome renderer path is the tier-1 threat vector and the thing that moves this from "server LPE" to "full device takeover" territory. Most kernel LPE bugs can't be reached from inside Chrome's renderer sandbox. Bad Epoll can. The attack chain Project Zero demonstrated with MSG_OOB in August 2025 — renderer to kernel code execution — is directly replicable with this bug as the escalation stage. A browser compromise becomes a full device takeover. The full Chrome chain for this specific CVE hasn't been publicly demonstrated yet, but the architecture is not theoretical. On Android: Pixel 10 runs kernel v6.6+. The UAF trigger is confirmed. The full root chain is described as "in progress." Pixel 8 and v6.1-based devices are not affected — the introducing commit isn't present. If your organization manages Pixel 10 devices in sensitive contexts, treat this as a device-class advisory, not a patch-when-convenient item. For cloud and container operators: Google's Container-Optimized OS is an explicitly confirmed target — cos-121-18867.294.100 is listed in the PoC. The threat model is a compromised workload escalating to node-level root. GKE operators should check node OS patch status now. The AI research angle is worth sitting with. Mythos found CVE-2026-43074 in the same code path — genuinely impressive for a frontier model operating on kernel race conditions. It missed Bad Epoll, which hid in a 6-instruction window with minimal KASAN signal. Almost no runtime evidence to flag. A human researcher connected the dots Mythos left on the table. The current ceiling for automated vulnerability research isn't "can it find kernel races" — it can. It's "can it find the ones that barely announce themselves." Not yet, apparently. Patch turnaround on the vendor side was slow. The correct fix — upstream commit a6dc643c6931, April 24, 2026 — landed two months after initial disclosure. The first maintainer patch was incomplete. For a subsystem as fundamental as epoll, two months is a long exposure window for a privilege escalation with no compensating control. Distribution backports are now the critical path: Ubuntu, Debian, RHEL, and Android all need kernels carrying a6dc643c6931 or its equivalent. Exploit-for-hire shops move faster than two months. They certainly move faster than nine days. CISA KEV listing not yet confirmed at time of writing. Given the public PoC reliability, that's a matter of when, not if.

• 
  R.Сам 🦋🐏 (@Logo_Daedalus) reported 12 minutes ago

  “AI” is a branding term for algorithms that have too “jargony” terminology, I think a major problem is the anthropomorphic PR language around it. There’s nothing “intelligent” going on in it’s just search algorithms on LLM vector spaces etc, but you say that & the investors tune out so you go “it’s maybe ALIVE & its got a NAME & maybe it will become GOD” & then they give you money to do something like “automating github search & integration” or “automating rotoscoping video clips” etc

• 
  One&OnlyAarav (@WaterAarav) reported 12 minutes ago

  Claude = coding. ($20/mo) Shypmenta = deploys, connects, and manages every platform below($6/yr) Supabase = backend. (Free) Vercel = deploying. (Free) Namecheap = domain. ($12/yr) Stripe = payments. (2.9%/transaction) GitHub = version control. (Free) Resend = emails. (Free) Clerk = auth. (Free) Cloudflare = DNS. (Free) PostHog = analytics. (Free) Sentry = error tracking. (Free) Upstash = Redis. (Free) Pinecone = vector DB. (Free) Total monthly cost to run a startup: ~$20. Building has genuinely never been this affordable, and rarely this effortless either.

• 
  zen (@trynothingy) reported 16 minutes ago

  nerds at github doing anything except fix their website 😭😭

• 
  Ali Mehdi Mukadam (@alimukadam) reported 20 minutes ago

  @trq212 Your weekly limits will burn away much faster during the limited availability if you aren't aware of this issue if you're running Fable as the lead agent with cheaper models like Sonnet doing work in the background problem: In one of the sessions, I noticed limits were burning through way faster, so I went digging through the transcripts when the main agent gives a job to a background model (like Sonnet, which I asked for to save tokens) and then comes back to give it more work, the background agent stops working on Sonnet and switches to Fable, the main agent's model it's not something you trigger by hand. the lead agent decides to check back in on its own as part of normal multi-agent work, so it just happens, with nothing on screen telling you it switched. in my case a task ran its first half on Sonnet exactly like I wanted, then silently ran the entire second half on Fable. It also dumps the cached context and rebuilds it from scratch, so you end up paying twice, once for the pricier model and once for the wasted cache. on limited availability and limits - that adds up quick my fix for now is a rule I dropped into my global CLAUDE.md so it doesn't recur: --------------- ## Model spend (all projects, all repos — standing rule) - Dispatching Frontier-tier (Fable/Opus) as background tasks and agents needs explicit approval by Ali for that specific lane — a prior approval is not standing permission for the next one. - Never resume a background agent via a message-passing tool that has no model-override param (e.g. SendMessage) if it needs real further work — it silently inherits whatever model the parent session is on right now. Let it finish and report, or kill it and respawn fresh with the model set explicitly. --------------- in plain terms: don't let a background agent get pulled back in for more work once it's running. either let it finish and report back, or kill it and start a fresh one with the model set on purpose. And this is already known. Someone reported the same thing on GitHub back on June 12, issue anthropics/claude-code#67794, still open their solution which I believe is the correct one but haven't tested yet: instead of setting the cheaper model when you launch the agent, pin it inside the agent's own definition file, and that version reportedly sticks even when the agent gets resumed

• 
  Steve Lauda (@stevelauda_) reported 22 minutes ago

  Github will do anything but fixing their uptime quality. I wonder what exactly goes in their executive weekly meeting. "Hey guys, our downtime still bad, what should we do?" "Ah, maybe our users would love to push their repo into CD-ROM, no more up-time, the repo stays with you forever, until the disc break ofc," "Ah yes, yes, write that down, write that down!"

• 
  Techjunkie Aman (@Techjunkie_Aman) reported 23 minutes ago

  @JasonBoxman Raise an issue in GitHub