GitHub at One Nine: Your CI/CD Has a New Single Point of Failure
The Numbers That Should Scare You
GitHub's effective availability has dropped to approximately one nine (~90%) — roughly 2.5 hours of degradation daily. The root cause: AI coding agent traffic, led by Claude Code, has grown 6x in three months, and GitHub's stateful infrastructure (databases, Redis clusters) cannot absorb the load elastically. This is just the beginning of the adoption curve.
Three incidents from February–March 2026 expose a deeper architectural problem. The Feb 9 database saturation is straightforward — databases don't scale horizontally. But the Feb 2 and March 5 incidents are more insidious: both involved failovers that triggered latent configuration bugs — security policies blocking VM metadata in one case, Redis write configuration issues in the other. These are the distributed systems failures that kill you at 3am: failover paths that work in testing but fail under production's accumulated configuration drift.
GitHub stopped updating its own status page, forcing a third-party replacement — a leading indicator of organizational dysfunction, not just infrastructure problems.
The Strategic Decay
GitHub is being absorbed into Microsoft's AI group without a CEO. Copilot has fallen to third place behind Claude Code and Cursor. Microsoft's incentive structure prioritizes Copilot revenue (declining in competitiveness) over core platform reliability. Mitchell Hashimoto's advice — kill Copilot, become the agent platform layer — is strategically correct but organizationally impossible. Plan for a GitHub that invests in the wrong things for the next 12–18 months.
What To Do This Sprint
Git is distributed by design — use that. A simple mirror to a secondary remote (GitLab, self-hosted Gitea, or even a bare repo on your own infra) gives you read access when GitHub is down. For CI/CD, self-hosted runners or a parallel system like Buildkite give you compute-level independence. Map every hard dependency: deployment gates, code review approvals, package registries, GitHub OAuth flows, GitHub Actions workflows.
If you operate any service consumed by AI coding agents, this is also your capacity planning wake-up call. AI agents don't follow human traffic patterns — they create, branch, push, and open PRs at machine speed with different concurrency models, different auth patterns, and fundamentally different storage profiles.
What to do
Map every system that hard-depends on GitHub availability (CI/CD, deployment gates, PR approvals, OAuth, Actions, package registry) by end of this sprint
Implement a git mirror to a secondary remote for your top 5 most critical repositories this week
Add a self-hosted runner fleet or Buildkite fallback for deployment-critical CI pipelines this sprint
Review your own services' API rate limiting and capacity planning for AI agent traffic patterns this quarter