Days without GitHub incidents

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.