GitHub has experienced eight major outages in two months—February through March 2026—failing to maintain the “three nines” (99.9%) availability standard it promises Enterprise customers. Three nines means 8.76 hours of allowed downtime per year. It’s not an aspirational target; it’s table stakes for business-critical services. Yet GitHub, backed by Microsoft’s virtually unlimited resources, can’t achieve what competitors like GitLab routinely deliver.
The pattern is damning. Database saturation on February 9. Security misconfigurations blocking VM metadata on February 2. Redis cluster failures on March 5. Webhook latency spiking 32x on March 18. Git operations degrading for eight hours on March 20. Developers on Hacker News (282 points, 149 comments) are asking the uncomfortable question: Is GitHub too big to maintain properly?
Eight Different Root Causes Reveal Systemic Failure
The February 2026 incidents alone paint a troubling picture. On February 2, a security policy applied to backend storage accounts blocked access to critical VM metadata, taking GitHub Actions and Codespaces offline for nearly six hours. All VM operations—create, delete, reimage—failed completely.
Seven days later, a configuration change reduced cache TTL from 12 hours to 2 hours, triggering massive cache rewrites that overwhelmed the database cluster. The Feb 9 incident combined five independent factors: new model release, Monday peak traffic, client app updates, reduced cache TTL, and compounding load. The Register reported that GitHub struggled to understand why read load kept increasing, prolonging the incident for hours.
March brought no relief. Redis writes failed on March 5. Codespaces broke across non-US regions on March 12. Webhook deliveries experienced 160-second latency spikes on March 18—up from 5 seconds baseline. West coast developers lost access to Git operations for eight hours on March 19-20.
These aren’t variations on the same bug. They’re architectural failures across disconnected systems. When eight different components fail in eight different ways over two months, the problem isn’t isolated incidents—it’s systemic brittleness.
The SLA Illusion: Why Service Credits Don’t Matter
GitHub Enterprise Cloud customers pay $21 per user per month for that 99.9% guarantee. When uptime falls below the SLA threshold, GitHub offers service credits: 10% refund for 99.0-99.9% availability, 25% for anything below 99.0%.
The math is absurd. A 25% refund equals $5.25 per user per month. Now calculate the real cost: 50 developers at $75/hour fully loaded, experiencing four hours of downtime. That’s $15,000 in lost productivity compensated by $262.50 in service credits.
Meanwhile, GitLab explicitly guarantees the same 99.9% SLA for its Ultimate tier. Atlassian promises 99.90% for Bitbucket Premium and 99.95% for Enterprise. GitHub isn’t falling short of some impossible standard—it’s failing to match what smaller platforms routinely achieve.
Service credit SLAs exist for legal protection, not economic compensation. They shift liability without actually solving GitHub reliability. Enterprises need uptime, not refunds.
Related: Amazon Invests $50B in OpenAI: AWS vs Azure Cloud War
Expert Analysis: GitHub Lacks Operational Flexibility
Lorin Hochstein, a reliability engineer with experience at Netflix and AWS, analyzed GitHub’s February incidents and identified a critical gap: responders lack “sufficiently granular switches” to control traffic during outages.
When the February 9 database overload hit, GitHub’s teams faced a binary choice: deny all requests or let infrastructure collapse. They couldn’t selectively shed load by service type, user tier, or request pattern. Hochstein’s assessment is blunt: “Providing responders with as many resources as possible before the next incident happens” means giving humans manual control, not just automated runbooks.
The February 9 incident revealed another failure mode: masked warnings. Database load was only visible during model or policy rollouts, hidden by cache TTL the rest of the time. Danger accumulated invisibly until catastrophic failure. Hochstein notes that “It took much longer to understand why the read load kept increasing, which prolonged the incident.”
Over-reliance on automation creates brittleness when novel failures occur. GitHub needs operational flexibility—the ability for humans to improvise under pressure. Right now, they don’t have it.
The Azure Migration Adds Risk, Not Reliability
GitHub is migrating its entire infrastructure from owned data centers to Microsoft Azure—a one to two-year transition driven by capacity constraints. The company officially stated it will “prioritize migrating to Azure over feature development” because current data centers, especially in Northern Virginia, can’t expand further.
This explains why GitHub downtime incidents are intensifying now. Infrastructure migrations are inherently risky. Services must be moved without disruption while traffic continues flowing and new features ship. The February-March outages may be symptoms of migration stress, not isolated failures.
Long-term, Azure offers virtually unlimited capacity to support Copilot’s growth and AI workloads. Microsoft has deployed hundreds of thousands of GPUs across its datacenter footprint specifically for AI infrastructure. But short-term, enterprises should expect elevated GitHub reliability risk for the next 12-24 months.
The irony cuts deeper: GitHub is migrating to Azure infrastructure to improve capacity and three nines availability, but the migration itself is causing reliability issues. Enterprises paying for 99.9% uptime are subsidizing GitHub’s architectural transition.
Developer Trust Is Eroding
The March 23 Hacker News discussion (282 points, 149 comments) captures mounting frustration. One developer: “GitHub Actions can’t even be called Swiss cheese anymore. Major overhauls needed.” Another: “How you manage to break something as basic as a git server in this way is beyond me.”
The conversation isn’t just venting—it’s migration planning. Developers are discussing GitLab alternatives, self-hosted options, and dependency risk. When the platform with the strongest network effects starts losing developer trust, that’s a structural shift.
GitHub hosts over 100 million repositories. It’s critical infrastructure for global software development. When GitHub goes down, CI/CD pipelines stop, code reviews pause, deployments fail. The entire software industry slows. Developers don’t want alternatives—but GitHub reliability failures are forcing the conversation.
Key Takeaways
- Three nines availability is table stakes, not aspirational—GitHub is failing to meet its own paid SLA commitment while competitors like GitLab deliver the same guarantee
- Eight different root causes mean systemic issues—database overloads, security misconfigurations, Redis failures, and network problems across disconnected systems reveal architectural brittleness, not isolated bugs
- Service credit SLAs are economic theater—getting $5 back doesn’t compensate for $15,000 in lost developer productivity; SLAs exist for legal protection, not real compensation
- Azure migration will cause 12-24 months of elevated risk—infrastructure transitions are inherently unstable; enterprises should plan for continued incidents as GitHub rebuilds its foundation
- Developer trust is eroding—Hacker News discussions about GitLab migration and self-hosted alternatives signal a structural shift; network effects won’t protect GitHub if reliability continues degrading
- GitHub lacks operational flexibility—responders can’t selectively shed load during incidents; over-reliance on automation creates brittleness when novel failures occur
