An update on GitHub availability
GitHub’s recent statement on its recurring outages, which blames a surge in AI- and agent-driven activity and outlines plans for multi‑cloud redundancy, has prompted sharp scrutiny from developers who rely on it as critical infrastructure. Many are frustrated by what they see as vague metrics, years of degraded reliability since the Microsoft acquisition, and a perceived overemphasis on Copilot and new features over core uptime. Others acknowledge the genuine engineering challenges of scaling git hosting to rapidly growing automated workloads, but are still exploring alternatives such as self‑hosted forges, GitLab, or federated models to regain control and resilience.
Azure, multi-cloud, and Microsoft’s role
- Many read “path to multi-cloud” as an implicit admission Azure alone is insufficient, especially for GitHub-scale reliability.
- Some note other Microsoft properties (e.g., LinkedIn) reportedly backed away from full Azure moves; others say multi-cloud is normal for resilience/vendor-independence.
- Several argue the Azure migration itself likely worsened reliability vs GitHub’s own datacenters; others counter that moving to any cloud is complex but not inherently doomed.
AI/agent-driven load and usage patterns
- Commenters accept that “agentic workflows” and LLM-generated code are driving huge spikes in commits, repos, and PRs.
- Debate over value: some say most of this code “goes to die” or is low-value “vibe coding,” not reflected in better end-user software.
- Several argue this traffic should be metered or priced (e.g., per-commit or per-usage), instead of subsidized as “free” load.
Reliability, user impact, and pricing
- Multiple users report frequent downtime and degraded performance (Actions, search, PR lists, UI glitches), sometimes costing real workdays.
- Paying customers complain that service quality is dropping while per-developer pricing stays high, especially given many workloads are just “static text files.”
- Some are migrating or considering moves to GitLab, Gitea/Forgejo, or self-hosting; others say GitHub’s functionality and ecosystem remain compelling.
Architecture, scale, and technology choices
- Discussion of GitHub’s historic Ruby-on-Rails monolith vs microservices; some nostalgically associate the monolith era with better stability, others say scale alone invalidates simple comparisons.
- Noted efforts: moving webhooks off MySQL, redesigning auth/session flows, shifting hot paths from Ruby to Go, dealing with monorepo pain, and general database/backend migrations.
- Some see frontend complexity (e.g., highly componentized React diff views) as a symptom of wider engineering/culture problems.
Graphs, metrics, and trust
- The unlabeled y-axes in GitHub’s growth charts are widely criticized as manipulative or meaningless; several call this “PowerPoint graphs.”
- New per-service uptime numbers imply only ~97% end-to-end availability; users say this matches their experience and is unacceptable for critical tooling.
- Many find the blog’s tone platitudinous (“we hear you”) and lacking hard numbers, concrete timelines, or genuine accountability, further eroding trust.