Days without GitHub incidents
Frequent outages at GitHub have prompted frustration and concern over the reliability of what many see as core infrastructure for modern software development. Commenters debate how much blame lies with surging AI-generated activity and GitHub’s architecture versus broader management and scaling failures at Microsoft, while also questioning status-page transparency and the ethics of defending a trillion‑dollar company. Many are now exploring self-hosted or alternative platforms, highlighting the risks of the ecosystem’s heavy dependence on a single service.
Overall view of GitHub’s reliability issues
- Many see GitHub as increasingly unreliable, with frequent outages affecting core workflows (push, PRs, Actions, releases).
- Some frame this as a serious business continuity risk; a few organizations are considering moving Enterprise from cloud to on‑prem or away from GitHub entirely.
- Others emphasize that complex systems do fail and argue for empathy toward the engineers operating them.
Load growth, AI, and scaling
- A reported ~14x YoY increase in commits is widely cited; many attribute this to AI agents generating numerous PRs per issue.
- Some argue 14x should still be manageable for a company with Microsoft’s resources and that pre‑existing architectural problems are being exposed rather than created by AI.
- Discussion highlights that CI/Actions compute, not just “serving text,” is likely the main scaling pain.
- Suggestions include throttling free tiers, gating CI on trust or pre‑review, and not triggering expensive builds for every random PR; critics worry such trust gates could harm open-source newcomers.
Status metrics and the “days without incident” site
- Opinion is split on aggregating outages into a single “days without incident” number:
- Pro: captures the user reality that if core features are down, GitHub is “down.”
- Con: overly simplistic; real status pages and per‑feature views are more informative.
- Some accuse official status pages of SLA “fudging” by segmenting services; others say segmentation is useful if you don’t depend on everything.
Responsibility, empathy, and corporate criticism
- One camp stresses accountability: paid, critical infrastructure should not degrade this much; comparing it to selling a service you know you can’t reliably deliver.
- Another camp emphasizes #hugops‑style empathy for staff, distinguishing workers from corporate decisions, and warning against armchair diagnoses of large‑scale distributed systems.
- Debate arises over compensation: higher pay is seen by some as reducing sympathy; others say you can be well‑paid and still feel demoralized and responsible.
Lock‑in, monopoly, and alternatives
- Several point to GitHub’s de facto dominance (e.g., stars influencing VC funding) and network effects as the real “monopoly” pressure.
- Others note many alternatives (GitLab, Forgejo, Gitea, self‑hosting, Phorge), and some report smooth experiences after migrating.
- Underlying theme: community has accepted large concentration risk for convenience, and the outages are prompting renewed interest in self‑hosting and smaller forges.