Disruption with Some GitHub Services – Resolved
Frequent outages at GitHub, particularly affecting Actions, are eroding developer confidence in what many consider critical infrastructure for modern software workflows. Commenters question why a service built on inherently distributed Git can still be taken down by issues like database primaries and infrastructure moves to Azure, and whether free and paid tiers should be isolated. Many are weighing alternatives such as self‑hosting (Forgejo, GitLab, Gitea, Enterprise Server) or data-residency variants, while noting the operational and political hurdles that make large organizations slow to migrate away.
Perceived Reliability and Outage Fatigue
- Many commenters see GitHub downtime as routine, to the point of jokes about “days since last incident” sites and treating the status page like a weather app.
- Several say GitHub used to be very stable but has become “literally a joke” for uptime in the tech community.
- Some argue this normalization is unhealthy for a critical industry service, especially for paying customers.
Status Page, Communication, and Monitoring
- Users report noticing issues before the status page updates, relying instead on HN, Reddit, X, and internal chats.
- Some criticize the level of operational detail on the public status page (e.g., “database primary failover,” “Vitess issues”) as amateurish or embarrassing; others welcome the transparency.
- There is interest in extensions and tools that surface GitHub status, but also strong pushback about security risks of installing random browser/VSCode extensions.
Architecture, Databases, and Scaling
- A visible update about failing over a “database primary” leads some to question why a single database can impact everyone and whether sharding/partitioning is adequate.
- Others explain RDBMS failover and replication are inherently hard; a “primary” doesn’t mean there’s only one database, and proxies and quorum logic add complexity.
- Vitess is mentioned as the distributed MySQL layer; it’s unclear whether problems are with GitHub’s use of it or upstream code.
Free vs Paid / Enterprise Segregation
- Many argue infrastructure for free, paid, and enterprise users should be split so paid users aren’t hit equally.
- Others note GitHub’s own postmortems point to operational, not purely scaling, issues; duplicating stacks would double operational burden.
- Confusion exists around different “Enterprise” products (github.com vs separate *.ghe.com deployments with data residency). Some enterprise customers say they are still affected like everyone else, others report higher uptime on separate infra.
Self‑Hosting and Alternatives
- A noticeable number are experimenting with or migrating to self‑hosted solutions: GitLab, Gitea, Forgejo, and various CI systems.
- Some praise Forgejo and note its GitHub‑like UX and Actions compatibility; others prefer GitLab’s CI design over GitHub Actions.
- There’s skepticism that many organizations will actually move, due to inertia, procurement complexity, and fear of running their own infrastructure.
Azure, AI Load, and Incentives
- Several connect rising outages with GitHub’s migration to Azure and reference critical write‑ups about Azure’s internal complexity.
- Others suggest the surge in AI‑driven activity (LLMs generating commits, Dependabot PRs, etc.) has stressed systems.
- Some propose simple mitigations like rate‑limiting free accounts; others argue internal politics and growth narratives likely block such moves.
Broader Reflections
- Commenters see GitHub’s struggles as emblematic of over‑complex, under‑owned big‑company systems.
- There is interest in more federated, self‑hosted git ecosystems to rebuild a shared “community” without single‑point corporate control.