An update on GitHub availability

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.