The Unicorn Took the Afternoon Off: GitHub Outages and Why Your Next Repo Belongs to You

The Day Everything Stopped

On August 17, 2026, I refreshed a pull request and got the page every developer dreads:

"No server is currently available to service your request."

The unicorn was back. Within minutes, the whole world seemed to hit the same wall. The website was flaking. The API was throwing 20% error rates. Archive and raw-file downloads were failing at a 50% clip. SAML and OIDC logins broke. And for the better part of eight hours, GitHub Actions — the thing an entire industry now uses to build, test, and ship software — sat dead in the water.

One developer in Germany summed up the mood perfectly: "Now I have to think again by myself."

Another, a principal AI observability engineer at a Fortune 50 company, told TechTarget the outage had him "fuming and considering an alternative. All of our work ground to a halt. We couldn't deploy, and our Actions were down."

Here's the thing about that quote: he said considering. Like most people, he then spent a week investigating his options and concluded the migration would take months. The lock-in was too deep. He stayed.

But not everyone stayed. And the more GitHub breaks, the more developers are asking a question that would have sounded absurd five years ago:

Should I just host my own Git server?

This post is my answer to that question. It's written for solo developers and hobbyists — people with a spare Raspberry Pi, an old laptop, or a cheap VPS, who are tired of their entire workflow depending on someone else's uptime. I'll walk through what actually went wrong at GitHub, who has already left, and what you genuinely gain — and lose — by taking your repositories home.

GitHub's Year From Hell, By the Numbers

GitHub used to be boringly reliable. For most of its first two decades, that was its quiet superpower. Then, somewhere between late 2025 and 2026, the boring stopped.

The incident tracker IncidentHub monitored GitHub for 12 months spanning mid-2025 to mid-2026 and counted:

• 257 incidents, of which 48 were major outages
• 112 hours and 18 minutes of major-outage downtime
• Roughly one significant disruption per week
• 37 incidents in February 2026 alone — the worst month on record

GitHub Actions was the most battered service, suffering 57 outages in that same year — which matters enormously, because an Actions outage doesn't just slow down a website. It freezes merges, queues builds, and halts deployments across every team that has automated its delivery pipeline around GitHub.

The reliability math is unforgiving. A "three nines" service level — 99.9% uptime, the benchmark GitHub's own COO has cited for enterprises — allows about 8.7 hours of downtime per year. The August 17 outage ran 7 hours and 47 minutes. One afternoon consumed nearly an entire year's reliability budget.

When the dust settled, GitHub Actions' trailing 90-day uptime sat at 99.33% — about 14.5 hours of accumulated downtime in three months, an order of magnitude worse than the underlying Git operations, which held steady at 99.99%. (Ironically, the foundational protocol — push, pull, clone — was the most reliable thing on the platform. It was everything built around Git that kept breaking.)

One developer on Reddit, after yet another incident, put it with characteristic bluntness: "Leave GitHub is the only solution. Money is the only thing they listen to."

Another thread on r/programming hit the same nerve: "It's never been easier to self-host git based source control and pipeline + runners. So many solutions."

Why Is This Happening?

GitHub's own CTO, Vlad Fedorov, has been unusually candid in a series of public posts. The short version of his explanation: the platform wasn't built for the scale it's now being asked to handle.

The numbers behind that:

• Monthly commits grew from 1.4 billion to 2.9 billion between April and August 2026
• GitHub started a plan to expand capacity 10× in October 2025
• By February 2026, that target had to be reworked — they now say they need to design for 30× today's scale

What's driving it? Largely, AI. Since late December 2025, "agentic development workflows" — AI agents opening pull requests, triggering CI runs, and interacting with repositories at machine speed — have exploded. Every automated agent is a new load profile: retries, API churn, repository traffic, background jobs. A single PR can touch Git storage, mergeability checks, Actions, search, notifications, permissions, webhooks, and multiple databases. At scale, small inefficiencies compound into cascading failures.

The other half of the story is a half-finished migration to Microsoft Azure. GitHub grew up in its own data centers, and it's now in the awkward middle of moving to the cloud — partly for capacity, partly by corporate mandate after Microsoft folded GitHub into its CoreAI organization. Azure now serves roughly 58% of GitHub's platform load, but the pieces that haven't migrated yet (like the Actions "launch service") have become chokepoints.

There were also plain old process failures. In April 2026, a regression in the merge queue feature silently reverted changes in 2,092 pull requests across 658 repositories. On February 9, 2026, an overstuffed user-settings cache overwhelmed a database cluster and knocked out login, Git-over-HTTPS, and Actions for hours. In November 2025, an expired TLS certificate broke all Git operations for an hour. A VS Code retry bug amplified Copilot traffic roughly tenfold during the August 17 recovery, dragging the AI assistant's outage on for hours after the main site was back.

The Exodus Has Started

When a platform everyone depends on spends a year being unreliable, people start leaving. Not all at once — but the departures that have happened are telling, because they're exactly the people who can leave.

Mitchell Hashimoto — co-founder of HashiCorp, creator of Vagrant and Terraform, an early and famously loyal GitHub adopter — announced in April 2026 that his terminal emulator project Ghostty was leaving GitHub. His diagnosis was blunt: GitHub is "no longer a place for serious work." He'd spent a month marking an X on every day an outage affected his work. Almost every day had one. On the day he wrote the post, a GitHub Actions outage had cost him two hours of pull request review.

Zig — the system programming language, a spiritual successor to C — migrated to Codeberg in November 2025. Its maintainers cited not just bugs but what they called a "rotted" engineering culture, pointing at a critical Actions bug reported in April 2025 that took months to fix while build servers hung indefinitely.

Tenacity (the audio editor), Dillo (the web browser), and Hare (the programming language) all moved or reduced GitHub to a mirror-only presence.

On Reddit, the mood shifted from "another outage, ugh" to "where are we going?" A thread on r/theprimeagen asked, only half-jokingly: "Is the Great Github Migration of 2026 happening? Where is the new cool place to be?" Answer threads were full of moving targets: Codeberg, self-hosted Gitea, Forgejo, GitLab, even old-school SSH-to-your-own-VPS.

A developer on r/software described the private-repo calculus many of us now face:

"After the recent GitHub breach stuff, the VSCode extension issue, and the constant outages lately, I've pretty much decided I don't want my private repos sitting entirely on GitHub anymore. I'll probably still mirror public repos there because realistically that's where everybody is, but private stuff is a different story."

That, right there, is the emerging consensus: GitHub keeps the public, the private comes home.

Self-Hosting: What You Actually Gain

Let me make the affirmative case now. As someone who has hosted my own Git server for personal work, here's what changed for me — and what's waiting for you.

1. Your Work Stops Only When You Decide It Stops

This is the big one, and it's the whole reason we're having this conversation. On August 17, 2026, tens of millions of developers discovered simultaneously that their ability to review code, merge PRs, and ship builds was owned by someone else's load balancers. When you self-host, the only person who can take your forge down is you.

Git operations themselves stayed at 99.99% uptime through GitHub's worst year. A self-hosted Gitea on a home server will be down far more often than that in absolute terms — your ISP will hiccup, your machine will reboot, you'll forget to renew a cert. But here's the difference: your downtime is scheduled, visible, and under your control. You're never blocked by an incident you can't even see the status page for.

2. Git's Founding Promise, Finally Honored

Git is fundamentally distributed. Every clone is a full backup of the repository history. Yet most of us have re-centralized our entire workflow around one company — the exact anti-pattern Git was designed to eliminate.

When you self-host, your primary remote lives on hardware you control. Push to it over your home network and a clone completes faster than GitHub can even negotiate TLS. Your code is your code, in a format you fully understand, with no third party in between.

3. Privacy, Without the Fine Print

Here's a question nobody at GitHub is answering to everyone's satisfaction: what happens to your code when the AI features run? GitHub has been explicit that it wants to train Copilot on the world's code. Some developers are fine with that for public repos. But private repositories are another matter entirely.

When you self-host, there is no ambient AI assistant reading your commits unless you install one yourself. No web scraper inventorying your private repos. No telemetry you can't see. For personal projects — especially anything that might be a future product — that's worth real money.

4. It's Free, On Hardware You Probably Already Own

GitHub's free tier is generous on paper, but as a solo dev you'll hit its edges: limited Actions minutes, storage caps, no private fork features in some tiers. Meanwhile, that Raspberry Pi in your drawer can run a full-featured Git forge.

Modern self-hosted forges are astonishingly light. Gitea and Forgejo idle around 80–200MB of RAM — a Raspberry Pi 3B+ handles them comfortably. Gogs runs on 256MB. Even a single-binary forge with CI can live on a $5/month VPS. GitLab CE, the heavyweight, wants 4GB minimum — overkill for solo use, but a mid-range laptop from 2015 handles it.

Compare that to the VPS you'd need to self-host anything else in your stack. Git hosting is one of the cheapest self-hosted services that exists.

5. Actions Without the Actions Drama

You don't give up CI/CD by self-hosting — you just run it on your own terms. Gitea and Forgejo both implement GitHub-Actions-compatible workflow syntax through their Action runners. Copy your existing .github/workflows/ files over, and many of them run as-is. No rewrite, no unfamiliar YAML dialect, no Marketplace dependency — just your containers running your builds on your hardware, with no minute caps.

6. You Actually Learn Your Stack

There's a quiet educational benefit that never makes the comparison tables. Running your own forge means you understand DNS, reverse proxies, TLS certificates, backups, and databases — because they're yours to keep alive. The skills are transferable to everything else you'll ever operate. There's a reason "ops/devops is going to be eating good as public services continue to degrade," as one r/programming commenter put it.

7. No Corporate Agenda

GitHub's direction is set by Microsoft's priorities. That means Copilot-first product decisions, AI evangelism from the CEO ("Either you embrace AI, or get out of this career"), policy shifts, and the occasional political controversy that has pushed projects out the door (Zig's maintainers cited GitHub's ICE contracts in passing). A self-hosted forge has exactly one stakeholder: you.

Your Options, Lightest to Heaviest

Here's the landscape as of 2026, ordered by how little hardware you need:

The Bottom Line

GitHub is not dying. It's too big, too embedded, too central to the open-source economy. The 180 million developers aren't leaving, and most of the ones who are will only leave partway — mirroring their public repos to Codeberg or keeping private work elsewhere while their public presence stays put.

But here's what the past year has changed, permanently: self-hosting stopped being an eccentric choice and became a rational one. The reliability math no longer justifies the "GitHub never goes down" assumption. The lock-in math for solo developers was always light — it just took a year of outages to make people look at it. And the tools have never been better: a full-featured forge that runs on a Raspberry Pi, with GitHub-compatible CI, migration tooling, and a mature ecosystem — all free, all yours.

So the question isn't "Is GitHub good?" anymore. It's "whose downtime are you willing to accept — theirs, or your own?"

For my personal projects, I've made my answer. I'm keeping the mirrors for the community, but the code that matters to me lives on hardware I control. When the unicorn appears on August 17th again — and statistically, it will — I'll still be shipping.

Note: figures and dates above reflect reporting published between mid-2025 and August 2026 (TechTarget, the official GitHub Blog, IncidentHub, HowToGeek, and community threads on Reddit and Hacker News). Availability numbers, star counts, and RAM figures vary by source; treat them as directional, not gospel.