GitHub Keeps Going Down. I Read the Post-Mortems and Priced the Exit.

Two things happened at the same time on Hacker News this week. GitHub fell over again, and an "Ask HN: Alternatives to GitHub" thread climbed past 600 points with roughly 400 comments. When those two show up together, the question stops being "was GitHub down" and becomes "should I actually care."

Here is the short version of what I found after reading the status page history, the post-mortems, and the migration threads: the outages are real and getting more frequent, the root causes are more interesting than "cloud bad", and the honest answer about leaving is that almost nobody should fully leave, but everyone should spend one afternoon making leaving possible. This article is that afternoon, written down.

A disclosure on sources: everything here comes from GitHub's official status page, public post-mortems, the Hacker News threads, and published migration guides, all linked inline. This is a research piece: the pricing of each option is documented public information, and the checklist is assembled from published migration guides rather than a production migration run for this article.

The outage record, in numbers

September has been rough. From GitHub's own status page:

• September 13: roughly 28 services degraded between 08:43 and 10:44 UTC. At peak, 96% of attempts to create an issue through the web interface failed. Account signup failures exceeded 90%. 8.8% of GitHub App token requests failed, and about 4% of Actions workflows were impacted because token issuance ran through the same broken path.
• September 15: Copilot code review jobs failed for hours because of latency in an internal caching service.
• August 26: a cluster of incidents hit Actions and Pull Requests. Third-party trackers logged the Actions disruption lasting close to three hours.
• August 17: three separate incidents on GitHub.com in a single day.

That is four degraded weeks out of five. Independent uptime trackers put GitHub's 30-day availability around 97%, which sounds fine until you multiply it out: roughly 21 hours of full or partial unavailability per month across their checks. For a code host, that is no longer background noise.

The Hacker News outage thread passed 550 points with over 900 comments. The alternatives thread that ran alongside it topped 600. People are not just complaining anymore. They are asking for exit plans.

What actually broke on September 13

The post-mortem GitHub published is worth reading slowly, because it is a textbook case of a failure mode every backend team carries. I will compress it to the chain:

• A background job started writing to a shared database. An internal data-cleanup job began at 07:33 UTC against a database cluster that stores permission data. That permission data is read on nearly every authenticated request on the platform.
• The safeguard watched the wrong signal. The job's pacing mechanism checked database replica lag. Replicas stayed healthy the entire time. Load was building on the primary, which nobody was watching. The job kept writing while the primary ran toward its connection limit.
• The primary exhausted its connections. Now every request that needed the primary started hanging, and because the database calls had no quick timeout, web request handlers waited instead of failing fast. Site-wide errors followed.
• A retry loop made it worse. Token creation had retry logic around it, so failing writes were re-sent continuously, holding the database saturated instead of letting it recover.

GitHub's fixes are the right ones and they generalize: rate-limit background jobs against shared customer-facing databases by default, page on primary load rather than replica lag alone, bound retries, add request-level timeouts, and split the shared cluster so authorization data stops being a single point of failure.

If you run any system where a cron job shares a database with user traffic, you have this exact bug sleeping in your codebase. The outage is not the story. The shared blast radius is.

The alternatives, and what each one really costs

The Ask HN thread produced a genuinely useful map. Here are the options that kept coming up, with the costs that rarely make it into the hype threads.

Codeberg, the hosted non-profit. Run by a German non-profit association, built on Forgejo, free for free and open-source projects. It has a published stance against AI training on hosted code, which is exactly why some people migrated. Gentoo started moving its public mirrors there in February 2026. The real cost is scale: it is volunteer-funded infrastructure, and teams using it for private company code are not its target audience.

Forgejo or Gitea, self-hosted. Single-binary forges that run comfortably in 1 GB of RAM on a cheap VPS. Both ship Actions-compatible CI, and existing GitHub Actions workflows carry over with minor changes. This is the option for a solo developer or small team that wants control. The cost is not the software, it is the operations: you now own backups, upgrades, uptime, and security patches for your own forge.

GitLab CE, the full platform. The closest feature-for-feature alternative for a large organization, and it can be self-hosted. The cost is weight. You are budgeting for PostgreSQL, Redis, and real operator time, and CI pipelines written in GitHub Actions syntax need translating to GitLab's format. If you migrate a big org, this is the only realistic destination, and it is a project, not an afternoon.

Sourcehut and Radicle, the edge cases. Sourcehut for terminal-first, email-driven workflows. Radicle if you want decentralized hosting with no central point of failure at all. Both are principled and both are niche. Most teams should know they exist and move on.

One pattern from the threads deserves honesty: the loudest "I migrated everything" stories came from individual developers, and their most common stated reason was not downtime. It was GitHub pushing Copilot and AI features into their workflow. Downtime starts the conversation. Policy and control finish it.

Why nobody actually leaves

If the alternatives are this good, why does GitHub still hold effectively the whole market? Three reasons, none of them technical.

• The network is the product. Your issues, PRs, stars, contributors, and CI history live there. A git repo migrates in minutes. The collaboration graph around it does not.
• Actions is the moat. Thousands of workflows depend on the marketplace and the hosted runners. The forges can run compatible workflows, but every third-party action you rely on is a migration line item.
• Outages end. Two bad hours is annoying. Rewiring your organization's entire development surface is expensive. Every outage thread ends the same way: everyone agrees in principle, nobody moves in practice.

This is why my actual recommendation is not migration. It is preparation.

The one-afternoon exit plan

Here is what I would do with any GitHub account you would genuinely miss losing, including the one this blog publishes through.

• Mirror every repo that matters. git clone --mirror each one, or run GitHub's built-in export if you need issues and PR data too. For most personal accounts this takes under an hour.
• Push the mirrors somewhere second. Codeberg for open source, a $5 VPS running Forgejo for private work. git push --mirror preserves branches and tags exactly. Now a GitHub outage is an inconvenience, not a hostage situation.
• Export the metadata you forget about. Issues, PR history, releases, and wiki pages do not travel in a git mirror. Forgejo and GitLab both have importers that pull repos and issues directly from a GitHub URL.
• Test one workflow on the alternative. Pick your simplest CI pipeline and get it green on Forgejo Actions or GitLab CI. That one green run is your honest estimate of the full migration cost.
• Decide what would actually trigger the move. Write it down. A multi-day outage? A policy change? A price change? Without a written trigger, you will re-litigate this every outage and act on none of them.

That checklist is the save-worthy part of this article. The outages will keep coming. Whether they cost you two hours of annoyance or two days of panic is decided by whether you did this once, calmly, while GitHub was up.

The part nobody says out loud

The deeper story in those Hacker News threads is not about GitHub at all. It is that a single company now sits on the collaboration layer of almost all the world's software, and its failure domain is our failure domain. The September 13 post-mortem showed that a single internal cleanup job with a misconfigured health check could take issues, PRs, Actions, and signups down together. That is not a GitHub flaw. It is what centralization looks like from the inside.

You do not have to leave to take that seriously. You just have to stop treating your forge as irreplaceable infrastructure. Mirrors are cheap. Options are cheap. Lock-in is the expensive part.

---

I write about developer tools, AI engineering, and the infrastructure underneath both, several times a week. Subscribe, it is free, and the exit plans and post-mortem breakdowns keep coming.

Do you keep mirrors of your important repos anywhere off GitHub, or does the whole operation live on one platform? If you have actually migrated to Codeberg, GitLab, or a self-hosted forge, I want to hear what it really cost in the comments.