GitHub having issues [resolved]

Repeated outages at GitHub, including a recent incident affecting Git operations, Actions, and Copilot, are raising concerns about the reliability of what has effectively become core infrastructure for software development. Commenters point to Microsoft’s push to migrate GitHub to Azure and prioritize AI products like Copilot over stability, noting a sharp increase in incidents and degraded uptime across services. Many are now weighing self-hosting or alternatives such as Codeberg, Gitea/Forgejo, and “break glass” CI setups to reduce dependence on a single, frequently failing provider.

Outage scope and status-page reliability

  • Many report 500 errors on git operations, pushes, pulls, CI fetch/checkout, and Pages; some note the status page initially showed only Copilot/Actions issues.
  • Several question how timely and truthful githubstatus.com is, though others point out that detailed postmortems and monthly availability reports are usually added later.

Perceived root causes

  • Strong belief that ongoing migration from GitHub’s own datacenters to Azure, plus aggressive AI/Copilot push, is degrading reliability.
  • Others suggest explosive growth in automated and AI-driven activity (e.g., massive repo cloning, frequent CI polling) may be overloading capacity.
  • Some argue corporate incentives favor visible AI features over less visible reliability work.

Uptime metrics and “how bad is it?”

  • Links to third‑party tracking show dozens of incidents in the last 90 days and ~98.8% recent uptime for Actions; some estimate “deep into one nine” overall.
  • Debate over impact: some think outages are overblown and teams should have other work to do; others at large orgs say repeated incidents materially disrupt thousands of people and automation chains.

GitHub as critical infrastructure / single point of failure

  • Discussion emphasizes how deeply CI/CD, deployment triggers, webhooks, package registries, and SSO/permissions depend on GitHub.
  • Outages demonstrate that many systems implicitly assume GitHub is always available.

Alternatives and self‑hosting

  • Suggestions: Codeberg, GitLab, Forgejo, Gitea, bare git+SSH on a VPS, simple hooks for deployments, and local/third-party CI.
  • Some report years of flawless uptime with self‑hosted setups; others counter that migrating large enterprises off GitHub, with all their integrations, is nontrivial.

Resilience and CI design

  • Strong advocacy for “break-glass” CI: the ability to run the same pipelines locally or in alternate CI when GitHub/Actions are down.
  • Recommended patterns: pipelines as scripts (e.g., build.sh), reproducible local runs, decoupling CI logic from CI infrastructure (e.g., with tools like dagger.io), and treating automation as codified runbooks.

Broader sentiment

  • Many see a decline from “beloved, stable Git host” to a frequently failing, enshittified platform under Microsoft.
  • Others note that dominant players often retain customers despite recurring downtime, due to lock‑in and risk aversion.