NextLens.Net

● GitHub Outage

The Question Raised Again by the GitHub Outage: Are We Really Developing by Trusting Only GitHub?

Starting with the key takeaway, this issue is not just a simple service outage

A GitHub outage is no longer something that ends as a “minor inconvenience.”
What this case revealed is that when one code repository stops, the entire development workflow can stop with it.
Pull Requests, Issues, Actions, Webhooks, releases, deployments, reviews, and collaboration history were all shaken at once.
What matters even more is that the status page appeared normal while actual work was blocked.
In other words, the gap between visible availability and real development productivity is much larger than many people think.
In this article, we will systematically review the real meaning of the GitHub outage, why GitHub has become this powerful,
and what companies and open-source projects should separate and prepare for now.
In particular, we will separately examine the core point that other news coverage often misses:
rather than asking “whether to leave GitHub,” the more important question is “whether we can keep operating even when GitHub stops.”

1. Why GitHub Outages Are Felt So Strongly

It is not just a server outage, but closer to a simultaneous stop of the entire development infrastructure

During this outage, errors occurred in about 20% of web and API traffic,
and in about 50% of archive and raw content downloads.
Pull Requests, Issues, Actions, and Webhooks were also affected.
The problem did not end there.
Even after recovery, situations continued where PRs were inaccessible while the official status page showed everything as normal.
From a developer’s perspective, this is a truly troublesome type of incident.
What is scarier than “there is an outage” is “a state where it is not even clear whether there is an outage.”

A recent characteristic of GitHub outages is their broad scope

In the past, one feature might have been briefly unstable.
Recently, however, the pattern has repeatedly involved different tasks being blocked one after another.
Representative examples include
an outage where Pull Request search results were missing and indexes had to be rebuilt,
an outage where GitHub Actions and Pages were affected for more than six hours,
and an outage where Issues, PRs, APIs, Webhooks, and Actions were affected at the same time.
In other words, the core tools that developers actually use are stopping in a bundled form.

There is a reason self-hosted runners did not move either

Many people think, “Isn’t it enough if the runner is on our own server?”
In reality, it is not.
The control plane that assigns jobs often remains with GitHub.
In other words, even if the computing resources are on your own server,
the core function that decides who runs which job and when is still held by GitHub.
This means that “we did not just place our repository on GitHub; we had also entrusted the backbone of operations to GitHub.”

2. There Is No Single Cause, but the Load Has Clearly Increased

AI agents, infrastructure migration, and old internal structures are all being discussed

Several interpretations are being raised as causes of recent GitHub outages.
These include a surge in commits, PRs, and Actions jobs generated by AI agents,
issues related to Azure infrastructure migration,
and problems with old internal structures.
It is difficult to pinpoint one exact cause,
but what is certain is that the workload the platform must handle has increased rapidly.

Actions usage has exploded even in numbers

According to figures shared by GitHub COO Kyle Daigle,
GitHub Actions runtime increased from 500 million minutes per week in 2023 to 1 billion minutes per week in 2025.
And in early April 2026, the weekly accumulated total reached 2.1 billion minutes.
This is not a number that can simply be concluded as “because of AI.”
However, it clearly shows that AI coding, automation, CI/CD, and release automation are putting enormous pressure on the entire platform.

What matters is the result more than the cause

Whether the cause is AI, infrastructure, or architectural limits,
what matters in the field ultimately comes down to one thing.
An outage in one service can stop the entire development process.
This feels even more significant in today’s AI era.
As AI creates code faster,
the platform bottlenecks that verify, deploy, and coordinate that code become even more visible.

3. GitHub Is Not Just a Code Repository

GitHub did not win simply because it hosted repositories well

GitHub did not win just because it was good at hosting Git repositories.
It won because, at the right time, it accurately captured a developer-centered collaboration structure.
Previously, the flow was centered around projects and users,
but GitHub changed the development flow into one centered around users and projects.
Forks, Pull Requests, issues, follows, discoverability, and social collaboration all entered one screen.
In other words, GitHub did not create just a repository service; it created a developer network.

What changed the open-source world was the convenience of centralization

In the past, the open-source ecosystem had separate servers, Trac, Subversion, mailing lists, and release pages for each project.
Autonomy was high,
but when a service disappeared, not only the code but also issues, discussions, and release history could easily disappear with it.
GitHub gathered these into one place so they could be preserved and discovered.
As a result, people became more comfortable,
and that convenience accumulated until GitHub became the de facto standard.

Why we cannot easily leave GitHub now

The reason is simple.
GitHub has solved too many problems well.
Code reviews, issue management, releases, packages, security alerts, Actions, collaboration history, search visibility, and contribution history
are all bundled together,
so separating them one by one costs more than expected.

4. Git Is Distributed, but the Development Process Is Not

Code is easy to move, but ways of working are hard to move

The Git repository itself is actually easy to move.
Every developer’s computer has the full history,
and you can add another remote repository or push to a new fork.
However, the core of modern projects lies more in forge functions such as PRs, Issues, Actions, and Releases than in Git itself.
This is where the problem arises.

GitHub dependency can be divided into four major layers

Code and Git history
This is the easiest part to replicate and move.
With regular mirrors or another remote repository, the risk of losing the code itself is greatly reduced.

Issues and Pull Requests
This part is much harder to move than code.
Long discussions, design decisions, review records, and cross-references are strongly tied to GitHub’s data model and URLs.
Exporting may be possible, but moving the full context as it is remains difficult.

Actions and the release process
This is the core point where an outage actually stops work.
If testing, packaging, deployment, and release creation are connected to Actions,
even with a repository copy, what you can do immediately is limited.

Identity and discoverability
This is the hardest part to move.
Stars, contribution history, search visibility, and familiar PR conventions do not follow just because a repository is copied.
Especially for open source, the cost of losing this network is greater than the cost of losing code.

5. Why GitHub Outages Feel More Sensitive in the AI Era

As AI coding increases, platform bottlenecks also grow

These days, AI agents quickly generate code, create PRs, run tests, and perform refactoring.
As this process increases, pressure on GitHub Actions, reviews, releases, and automation pipelines grows.
In other words, AI increases productivity while also increasing platform dependency much faster.

The center of development productivity has moved from the local IDE to the platform

In the past, the time spent writing code on your own computer was the most important.
Now,
creating PRs,
running automated tests,
getting reviews,
and deploying
have become more important.
So when GitHub stops, the problem is not “we cannot write code,” but “we cannot finish the work.”
This difference is bigger than it may seem.

6. The Realistic Exit Strategy Shown by Ghostty

The core point is not to leave all at once, but to gradually reduce dependency

Ghostty said it would leave GitHub,
but it did not first decide exactly where it would go.
This is important.
Instead of moving blindly,
it chose a method of gradually reducing GitHub dependency while leaving a read-only mirror at the existing GitHub URL.
This means that
rather than “completely abandoning GitHub,”
it is more realistic to first build a structure that can operate without GitHub.

The most important things when leaving GitHub are URLs and context

The reason many projects hesitate to migrate is not simply the repository.
Existing issue links, PR links, review records, search visibility, and community inertia all move together.
That is why leaving a read-only mirror
and gradually moving only the main workspace is a much more realistic strategy.

7. There Are Many GitHub Alternatives, but There Is No Single Replacement

The answer changes depending on what you are willing to give up

Other managed forges
These are services such as GitLab or Codeberg that provide repositories, issues, reviews, and CI together.
Migration is relatively easy, but the structure of depending on a central service does not change much.

Self-hosted forges
This is the approach of operating Forgejo, Gitea, or GitLab yourself.
You can control data and policies, but you must personally take responsibility for upgrades, backups, security, email, and runner operations.
It is realistic for small teams or internal projects.

Lightweight Git hosting
These are minimal-function approaches such as SourceHut, cgit, and stagit.
They are fast and simple, but you must give up GitHub-style PRs and social features or learn an email-centered workflow.

Federated or P2P forges
These are approaches such as Forgejo Federation, Radicle, and Tangled that try to reduce dependence on a central operator.
They are interesting in the long term, but they are not yet mature enough to fully replace everyday collaboration experiences.

Moving to an alternative does not eliminate policy risk

An important point is that moving to another central service
does not make you completely free from that platform’s decisions and policies.
In the end, it may simply mean choosing another operator’s judgment instead of Microsoft’s judgment.
That is why “where should we go?” is less important than “what should we place where, and what should we extract?”

The issue of free CI runners is surprisingly significant

One reason public projects cannot easily leave GitHub is free CI.
The ability to use not only Linux but also Windows and macOS runners for free is quite powerful.
If you move to another forge, not only the collaboration method changes,
but new costs that did not previously exist may also arise.
This issue is especially large for open-source projects that require multi-platform testing.

8. The Most Important Point Often Missed by Other YouTube Channels or News Coverage

The real problem is not the outage, but the “unseparated responsibility structure”

The most important message from this issue is this.
We think we are using GitHub only as a repository,
but in reality, we had entrusted reviews, automation, deployment, releases, collaboration history, and discoverability to it all at once.
In other words, when an outage occurs, what stops is not a server, but the organization’s way of working.

What must be done before leaving GitHub is separation

The most realistic strategy is not a full migration.
First, you must separate the work that must continue even when GitHub stops.
Code must also exist elsewhere,
release paths must be recoverable separately,
and documentation and decisions must not remain only in PR comments.
Only then can GitHub dependency truly be reduced.

In the end, the question is this one thing

If GitHub stops for several hours,
what exactly stops in our organization?
The response differs depending on whether only reviews are delayed,
deployments are blocked,
or emergency recovery becomes impossible.
If you cannot answer this question,
you are likely to be shaken in the same way during the next outage.

9. A Checklist Companies and Open-Source Projects Should Review Right Now

Items to check immediately from an operations perspective

You should check whether you have an independent remote repository or regular mirror.
You should also test whether you can actually restart work from that mirror.

You should review whether important design decisions and operational procedures exist only in PR comments.
If necessary, they should be moved into repository documentation.

You should also check whether Issues, PRs, Releases, and Wikis are being preserved regularly.
More important than leaving records is verifying whether they are recoverable.

You should check whether there is a minimum release path when GitHub Actions stops.
Simply adding a self-hosted runner is not the end.
You must also check where job assignment and authentication remain.

For open source, a strategy that separates a read-only mirror from the main workspace is also worth considering.
This approach maintains a familiar entry point for contributors while reducing internal dependency.

10. Should We Eventually Leave GitHub?

The answer is neither “leave unconditionally” nor “you can never leave”

For personal projects, it is easy to try another forge.
If you do not need every GitHub feature, Codeberg, SourceHut, or a self-hosted forge may be enough.

For public open source, the migration cost is much higher.
New accounts, reduced discoverability, and changes in contribution procedures can lead to an actual decrease in participation.
That is why a gradual migration approach like Ghostty’s is more realistic.

For companies, deciding to stay with GitHub can also be fully reasonable.
The cost of rebuilding the permissions, Actions, security, and deployment ecosystem already in place
may be greater than a few hours of outage.
Even so,
you must clearly define what stops when GitHub stops.

Summary

The GitHub outage was not merely a service interruption, but an event that exposed the vulnerability of the entire development workflow.
The core point is not whether to leave GitHub immediately, but whether the structure has been separated so work can continue even when GitHub stops.
As AI coding and automation increase, dependency on Actions, PRs, deployment, and releases will grow even more.
There are many alternatives, but the answer is closer to “dependency separation” than “migration.”
What is needed now is not an escape, but a recoverable design.

[Related Articles…]

Development Infrastructure Checks That Become More Important as GitHub Outages Repeat

Automation and Platform Dependency Reshaping Developer Productivity in the AI Coding Era

*Source: https://news.hada.io/article/github-is-not-just-git