GitHub Reliability, Merge Errors and Developer Trust

GitHub has shaped my life for roughly 15 years: my projects, jobs, friendships and understanding of open source all grew there. That is why its recent reliability problems hurt. I could not load the pull requests I needed for T3 Code for much of a workday, and a separate merge-queue incident raised a deeper concern about whether changes would persist.

An outage that prevents a page from loading is frustrating. An incorrect merge can be worse: a deployment may already contain changes that a subsequent merge removes from the branch. Debugging the difference between the running system and repository history can be painful, especially if database migrations are involved.

I am also unhappy with how leadership described the merge incident. My criticism is about the seriousness of the failure and the need for accountability. The question is no longer just whether a page is slow; it is whether maintainers can trust the infrastructure on which they coordinate and ship software.

A chart of GitHub’s average reported monthly uptime suggests a decline, but its vertical axis begins near 99.5%, and reporting or measurement may have changed over time. I would not infer an exact historical trend from the graph alone. The way incidents are measured matters as much as the picture.

An independent status-page view counts a period as affected when any tracked component has an incident. It displayed 86.75% for its preceding 90-day window in the video. That is not a claim that the entire GitHub service was inaccessible for 13.25% of the time; it is a broader measure of reported component incidents.

Reliability has several dimensions. Does a feature still behave as it did yesterday? Is it available when I need it? And does work that I completed yesterday remain intact? A change in any one of those can reduce trust, but losing previously completed work feels especially dangerous.

I have complaints about navigation, pull-request performance and the command-line experience, but those are not the immediate reason people consider leaving. Availability and correctness are more basic. If the service is unavailable when a team needs to ship, a workflow that depends on it becomes fragile.

I remember an outage during a trip around 2022. A customer needed an urgent fix to a video service; I tested the changes and merged them, expecting the Vercel integration to deploy. GitHub webhooks were having problems, so the deployment never arrived as expected.

Webhooks notify another service that something has changed, allowing a merge to trigger a build or deployment. In that incident I was told some deliveries were delayed and others did not arrive. I eventually deployed manually with the Vercel CLI. A missing event in one service had blocked a fix elsewhere.

That experience began to erode trust in something I had taken for granted. GitHub was not just a code browser to me: I learned by reading issues, pull-request discussions and maintainer profiles. Seeing how people work together was as important as reading their source code.

For a long time I considered Microsoft’s stewardship a net positive, including the move to make private repositories available without a paid plan. I kept paying because I valued the service. Git and GitHub are different things, but GitHub had felt almost as dependable as the Git installation on my computer.

More recent incidents have made that assumption difficult to sustain. I distinguish a temporary failure to use a service from a failure of the state users expect it to preserve. A merge that produces incorrect history has consequences that can continue after the status page says the incident is over.

Imagine merging a change with a database migration and deploying it, then discovering a later merge removed the change from the branch. The deployed system and the branch may disagree; blindly applying the change again can compound the problem. This is why I find merge correctness more worrying than ordinary downtime.

GitHub’s postmortem says the April 23, 2026 regression affected squash merges through merge queue when a merge group contained multiple pull requests. Subsequent merges could inadvertently revert earlier changes; it reported 2,092 affected pull requests during the impact window. The official account is at https://us.githubstatus.com/posts/details/PXT8RAY.

The post I read from COO Kyle Daigle cited 2,804 affected pull requests out of more than four million merged that day, said the issue was fixed and customers contacted, and promised more tests. The later incident report uses a different count and narrower description; readers should not assume those figures are interchangeable.

I object to language that, in my view, minimizes what it means for changes to be reverted. A percentage over the whole day does not tell an affected team how to repair its repository. I want a direct explanation of the failure, an apology and evidence that the safeguards will improve.

My concern about accountability also extends to leadership. At the time of the recording, I understood GitHub to be operating without its own CEO after the previous CEO left, with leadership reporting into Microsoft. I believe a service this important needs a clearly accountable leader who can prioritize its health.

I disclose that I have invested in the former GitHub CEO’s new venture, which is exploring Git workflows and could eventually compete in this space. It is early, and that investment is relevant context when I discuss GitHub’s leadership or potential alternatives.

I argue that when a company lacks a single leader focused on the product, it becomes harder to assign ownership of systemic failures. That is my organizational diagnosis, not evidence that any particular executive intentionally caused an outage or that an outside business interest explains these events.

I also describe what I understand to be a separation between GitHub’s product and engineering organizations. I cannot establish the full internal reporting structure from outside, but my concern is practical: if teams responsible for what users need and how systems are built are too distant, important reliability work can fall between them.

At Twitch, the product manager worked closely with my engineering team. They did not need to know every implementation detail, but they understood the product and participated in our decisions. For a developer product, I would expect particularly close collaboration between product and engineering.

Separate reporting lines can work when someone has the responsibility and authority to coordinate them. My criticism is that, without effective coordination, teams may optimize their own parts while the overall user experience deteriorates. I want GitHub to prove this diagnosis wrong through visible improvement.

A separate security disclosure also affected my confidence. Wiz researchers found a remote-code-execution vulnerability in GitHub’s handling of Git push options. GitHub says it validated the report, fixed github.com in under two hours and found no evidence of exploitation in its investigation: https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/.

The vulnerability was disclosed publicly after it had been reported and fixed; it should not be confused with proof that millions of repositories were actually compromised. Still, the potential impact of a flaw in a central code-hosting service makes rapid remediation and transparent investigation important.

Mitchell Hashimoto announced that Ghostty planned to leave GitHub. He wrote about using GitHub almost daily since 2008 and the emotional weight of moving a project away from a place that had been central to his work. That reaction resonated with me because I learned and built my career there too.

Hashimoto described studying maintainers’ reactions to issues and pull requests, not merely their code. I learned the same way. Open source made the people and the process visible, giving newcomers examples of how to review, discuss and maintain real software.

He said that repeated outages had disrupted his work on most days in a journal he kept. At the time of the announcement, Ghostty planned an incremental migration, with a read-only GitHub mirror retained and his personal projects remaining there for the time being. This was a plan, not an announcement that every project had already moved.

The announcement is painful because the platform was more than a host. It gave maintainers a shared place to work and gave people like me a way to discover projects, find collaborators and demonstrate what we could build. Losing confidence in it means reconsidering an entire community workflow.

I recently went back to the T3 Code pull-request tab and found it still would not load hours later. Maintainers have to respond to users and review contributions even when the platform is struggling. I feel a responsibility to speak for that open-source community, while recognizing that people inside GitHub are working on these problems too.

I also raise Tanner Linsley’s report about an unscoped npm package named tanstack, which he said was not controlled by the TanStack project. He had sought control of the name. I describe a report that a package under that name carried a script intended to steal environment data.

A package name and an organization scope are distinct: an unscoped lookalike should not be conflated with the project’s legitimate @tanstack packages. My account of the prior name dispute and the other party’s motives is based on what I was told; the timing and responsibility for the malicious code require separate evidence.

This expands my reliability framework to a fourth question: can the platform protect users and their work from security abuse? My argument is that availability, consistent behavior, persistence and security all contribute to trust. A platform can respond well to one incident and still need broader improvement.

I mention GitLab, Gitea and Bitbucket as possible directions, but I do not make a migration recommendation in this video. Moving code is only part of the work: issue history, reviews, CI, webhooks and the community around a project all have to be considered. I plan to evaluate alternatives in a follow-up.

I want an accountable leader, closer product and engineering coordination, and a concrete roadmap for reliability. More than promises, I want to see fixes working. My frustration comes from caring about the people who rely on GitHub and wanting it to deserve their trust again.

For now I cannot recommend GitHub with the confidence I once had, and I intend to investigate alternatives. I would be glad to be proved wrong if the service improves; what matters to me is sustained, observable reliability for the people building software on it.