There’s a scene in Anchorman where Brian Fantana describes his cologne: “60 percent of the time, it works every time.” The line is funny because it’s nonsensical. No rational person would brag about those numbers.
Enter GitHub, circa 2026.
According to an unofficial — but meticulously reconstructed — status page built by a developer named Marek Šuppa (hosted, with delicious irony, on GitHub), GitHub’s platform-wide uptime dropped below 90 percent at one point in 2025. And 2026 hasn’t exactly been a victory lap. Eight major outages across February and March. Database saturation. Redis cluster failures. Webhook latency spiking 32x. Git operations going dark for eight hours on the West Coast. Copilot rate-limiting paying Pro+ customers because someone accidentally shipped an internal test config to production.
Ninety percent uptime. Let that sink in. That means GitHub was effectively offline for the equivalent of over 36 days a year. Your local taco truck has better availability than that, and Juan doesn’t even have an SLA.
The Parade of Outages
Let me walk you through a greatest hits of the February-March 2026 GitHub incident timeline, because honestly it reads like a slapstick screenplay:
February 2: GitHub Actions and Codespaces go down across all regions. The root cause? A telemetry gap caused security policies to accidentally lock out internal storage accounts. Every single hosted runner type was affected. Copilot coding agent, CodeQL, Dependabot, GitHub Pages — all collateral damage. Self-hosted runners were fine, which is the infrastructure equivalent of “the building is on fire but the parking lot is okay.”
February 9: Five separate incidents in twelve hours. Pull requests, webhooks, issues, Actions, and Git operations all experience intermittent timeouts. Copilot goes down. Notification delays hit 50 minutes. The Hacker News thread hit 289 points and 315 comments, with developers reporting the web UI was “mostly unusable.” One developer on Hacker News summarized: “GitHub Actions can’t even be called Swiss cheese anymore. Major overhauls needed.”
February 12: Codespaces fails across Europe, Asia, and Australia with a 90% failure rate. US regions were fine. GitHub essentially told an entire hemisphere to go touch grass.
March 5: An automated Redis failover — the kind that’s supposed to prevent outages — triggers a cascading failure because of a latent configuration issue. The failover left the cluster with no writable primary. It’s like installing a smoke detector that, upon detecting smoke, also sets fire to your kitchen.
March 12: Codespaces breaks again, this time across non-US regions. Again.
March 18: Webhook delivery latency spikes from 5 seconds to 160 seconds. That’s a 32x increase. For context, if your morning commute got 32x worse, you’d be driving from Las Vegas to your office in Reno.
March 19-20: West Coast developers lose access to Git operations for eight hours. The Copilot Coding Agent hits a 99-100% error rate during the second incident because of an authentication issue with its backing datastore. The fix? Rotating credentials. The second outage happened because the first fix was incomplete.
March 24: Microsoft Teams integration goes down because of — and I promise I’m not making this up — an outage in Microsoft’s own Azure Teams APIs. GitHub blamed its “upstream dependency.” The upstream dependency is also Microsoft. It’s Microsoft all the way down.
March 27: A rate-limiting configuration meant for internal staff testing gets accidentally applied to production. Sixty-six percent of Pro+ users — the people paying the most money — get locked out of Copilot. The people paying nothing? They were fine, percentage-wise. It’s a beautiful inversion of how premium services usually work.
March 30: Actions experience degraded performance because planned database maintenance triggered write throttling guardrails. The infrastructure team was trying to improve things.
March 31: Billing usage reports tank with error rates peaking at 98%. At least they couldn’t charge you while the billing system was down. Silver linings.
The Azure Migration Is A Self-Inflicted Wound
What’s causing this reliability crisis? GitHub has been in the process of migrating its infrastructure from its legacy data center to Microsoft Azure since October 2025. Actions and Copilot migrated in 2024. Pages and Packages in 2025. The rest is still in transit.
This is like trying to replace the engine of a 747 mid-flight while simultaneously adding a hot tub to first class.
Here’s the part that makes infrastructure engineers weep into their on-call pagers: GitHub’s original infrastructure was working. Not perfectly, but it was working. The migration to Azure was driven by corporate alignment with Microsoft — a strategic decision, not an engineering necessity. And they chose to do this while AI coding agents were exploding the platform’s traffic by 5-6x.
GitHub’s own CTO said in 2025: “For us, availability is job number one, and this migration ensures GitHub remains the fast, reliable platform developers depend on.” The Hacker News community’s response was predictable. One commenter: “That went about as well as everyone thought back then.”
The Zig programming language literally quit GitHub over this. Andrew Kelly, the Zig Foundation president, moved the entire project to Codeberg, calling GitHub’s infrastructure “crumbling” and its Actions service “vibe-scheduling — choosing jobs to run seemingly at random.” When Microsoft acquired GitHub in 2018, Kelly’s reaction was: “Please just give me five years before everything goes to shit.” He got seven. That’s the optimistic reading.
My Theory: AI Made Code Disposable
But here’s the thing nobody is talking about, and I think it’s the elephant in the server room.
Why are we even storing code anymore?
Think about it. AI is now writing most of the code. GitHub Copilot, Claude Code, Cursor, Codex — developers are generating code at 5-6x the rate they were a year ago. One developer on Hacker News admitted their commit volume went up 600% purely from AI agents. These tools clone repos, generate changes, create branches, open PRs, trigger CI, and iterate — every few minutes.
So you’ve got AI writing code, pushing it to GitHub, where another AI reviews it, and a third AI runs tests on it. At what point did we stop and ask: why are we paying someone to store all this?
If AI can regenerate the code every time you need to change your application, what exactly is the point of a repository? It’s like meticulously archiving every Post-it note you’ve ever written. The AI doesn’t need your git history. It doesn’t care about your lovingly crafted commit messages. It’ll just write it all again from scratch — and probably better, because it won’t carry forward that weird architectural decision you made at 2 AM in 2019 after your third Red Bull.
Maybe GitHub’s uptime problems aren’t a bug. Maybe they’re the universe telling us that the entire concept of “storing code” is a relic of the human-authored software era. You wouldn’t carefully preserve a ChatGPT response in a climate-controlled vault. Why are we doing the equivalent with AI-generated code?
GitHub is basically a storage unit for digital hoarding at this point. And just like every episode of that A&E show, the storage unit is falling apart.
Did Microsoft Lay Off the People Who Know How Things Work?
Speaking of things falling apart, let’s talk about Microsoft’s 2025 layoffs. Over 15,000 jobs were cut across the year — 6,000 in May, another 9,000 in July. Engineering, product management, cloud, GitHub, Xbox, LinkedIn — nobody was safe. The cuts extended across every platform Microsoft touches, and reports indicate significant reductions in software engineering and product management roles at Redmond headquarters.
The stated reason? “Adapting for future growth.” The actual reason? They’re spending $80 billion a year on AI data centers and GPUs, and that money has to come from somewhere. In corporate finance, “workforce efficiency” is what you call it when you fire the people who know where the bodies are buried.
Now, I’m not saying Microsoft laid off the specific people who knew how to keep GitHub’s Redis clusters healthy, or understood the quirks of the legacy data center infrastructure, or remembered why that one config flag exists. But I’m not not saying it either.
A reliability engineer who worked at Netflix and AWS analyzed GitHub’s February incidents and identified a fundamental problem: responders lack fine-grained controls to manage traffic during outages. When things go wrong, GitHub’s teams face a binary choice — deny all requests or let the infrastructure collapse. There’s no middle ground. That’s not a technology problem. That’s a knowledge problem. Someone who understood the system deeply enough to build those controls either never existed, left, or got reorganized into a team building yet another Copilot feature.
Microsoft cut 15,000 people and then wondered why their systems started breaking. At some point, the institutional knowledge that keeps complex distributed systems running walks out the door with a severance package and a LinkedIn “open to work” banner. You can’t replace that with a GPU. Trust me, I’ve been building enterprise systems for over 30 years. The person who knows why the sleep script spins forever on CI machines under load? You can’t train that knowledge into a new hire in a two-week onboarding.
The FrontPage Prophecy
You know what this whole situation reminds me of? Microsoft FrontPage.
For the younger readers — or anyone who has mercifully blocked this from their memory — Microsoft FrontPage was a WYSIWYG web editor from the early 2000s. Part of the Office suite. It let normal people build websites without knowing HTML, which sounds great until you realize what it actually did.
FrontPage had two views: Design View and Code View. You’d carefully write your HTML in Code View, getting everything just right — your clean, semantic markup, your properly nested tables (it was the 2000s, don’t judge me). Then you’d click over to Design View to see how it looked. Fine. Beautiful. You’d click back to Code View and... FrontPage had rewritten your code.
It would inject proprietary Microsoft tags. It would restructure your layout. It would add <font> tags you never asked for. It would mangle your CSS. Every round trip between the two tabs was like a game of telephone with a drunk translator. Your code went in clean and came out looking like it had been through a blender. The infamous _vti_ directories. The FrontPage Server Extensions. The gratuitous proprietary markup that made your pages only render correctly in Internet Explorer.
The web development community’s relationship with FrontPage was essentially an abusive one. It “helped” you, the same way a toddler “helps” you cook dinner.
Time for GitHub FrontPage Mode?
And here’s my modest proposal for 2026: maybe it’s time for GitHub to bring back the FrontPage philosophy.
Think about it. GitHub’s servers are groaning under the weight of AI-generated code. Developers are committing at 5-6x their previous rate. AI agents are pushing slop to repositories every few minutes. The servers can’t keep up. Uptime is cratering.
So why not have GitHub do what FrontPage did? Every time you check in your AI-generated code, GitHub runs it through its own AI that compacts it, rewrites it, and optimizes it for storage. You push 500 lines of boilerplate that Claude wrote for you, and GitHub’s AI compresses it down to 50 lines of dense, incomprehensible-but-equivalent code. You check out the repo later and it looks nothing like what you checked in — just like clicking between Code View and Design View in FrontPage.
Call it GitHub FrontPage Mode. Or better yet, GitHub Vibe Storage.
Your AI writes the code. GitHub’s AI rewrites the code. The next developer’s AI rewrites it again. At no point does a human read any of it. It’s AIs all the way down, passing code back and forth like a game of hot potato where nobody actually wants to hold the potato.
This solves everything. Uptime improves because there’s less data to store. Storage costs drop. The Azure migration finishes faster because there’s less to migrate. Microsoft can lay off even more people because nobody understands the code anyway. It’s perfect.
Sure, your git blame history will be meaningless. Your diffs will be incomprehensible. Your carefully crafted abstractions will be flattened into a single 10,000-line function called doEverything(). But who cares? The AI will just regenerate it all next time. And if GitHub is down when you need it? No worries — just ask Claude to write the whole application from scratch. It’ll take about 45 seconds.
The Bottom Line
GitHub Enterprise Cloud promises 99.9% uptime. They’re delivering somewhere in the neighborhood of “well, it works most of the time.” Developers on Hacker News are openly discussing migration to GitLab, Codeberg, and self-hosted options. The Zig project already left. The trust erosion is real.
When developer Corey Quinn (a.k.a. @QuinnyPig) tweeted on March 4th, “My complaints about GitHub reliability lately haven’t just been shitposting; serious companies are taking notice of the platform’s availability woes,” that wasn’t just commentary. That was a canary in the coal mine.
GitHub hosts over 100 million repositories. It’s not a product anymore — it’s infrastructure. When GitHub goes down, CI/CD pipelines stop, code reviews pause, deployments fail, and millions of AI coding agents just... sit there, confused, like a dog that’s been told to stay.
But maybe that’s fine. Maybe in 2026, the concept of “storing code” is as quaint as saving your FrontPage websites to a floppy disk. AI will write it, AI will test it, AI will deploy it, and AI will rewrite it from scratch when the server inevitably goes down again.
90 percent of the time, it’s up all the time.
And 100 percent of the time, nobody’s code is really theirs anymore anyway.
If you enjoyed this article, subscribe for more takes on the beautiful chaos where enterprise software meets the AI revolution. And if you’re a GitHub engineer reading this during an incident — I’m sorry, and also, your Redis cluster is on fire again.