I am not leaving GitHub any time soon

I created my GitHub account in October 2011. User 1,100,970. My first repository was a small project for an openSUSE summit, pushed in February 2012. I’ve opened GitHub almost every day since then for nearly fifteen years. It’s where most of my professional life has happened.

So when Mitchell Hashimoto wrote last week that GitHub “is no longer a place for serious work” and that he’s moving Ghostty off the platform, I paid attention. Mitchell is user 1,299, joined in 2008. When someone with that history says they’re done, it means something.

I am a loyal GitHub user. I am also, right now, an unhappy one.

The reliability is bad

GitHub’s April has been a mess. On April 17, caching saturation in one data center caused about 1.5% of web requests to fail. On April 21, the projects service was degraded for nearly twelve hours. On April 22, Copilot’s coding agent dropped roughly 23,000 pull request and issue comment invocations. On April 23, a merge queue regression produced incorrect merge commits that accidentally reverted changes from previously merged pull requests across 658 repositories and 2,092 PRs. On April 27, an Elasticsearch overload took down search-backed features across the platform. As I write this on April 29, Elasticsearch reindexing is still ongoing.

Five significant incidents in under two weeks. According to The Missing GitHub Status Page, a community-built reconstruction of the uptime data GitHub stopped publishing, April’s uptime has dropped below 85%. This didn’t start in April either. February had two major outages, the worst of which stemmed from an overloaded database cluster handling authentication. March had another. GitHub themselves have acknowledged tight coupling between services, insufficient isolation, and load management failures as root causes.

I’ve had plenty of those days too.

But I’m not leaving

GitHub is where my entire professional and personal coding life lives. My code is there. Code review from my peers and the open source community is there. My CI runs are there. My issue tracking is there. Fifteen years of contribution history, trust, and reputation are there. It’s a complete experience in a way that nothing else is, and that completeness is what makes it so hard to walk away from, even on the bad days.

Then there’s the craft. GitHub’s attention to detail reflects eighteen years of thinking about how developers actually work. Pull request reviews feel considered, issues and discussions flow into each other naturally, keyboard shortcuts that just work, and the information density somehow never feels cluttered. Design is how you think about the user, and no other provider has thought about developers as long or as carefully IMO.

I’ve tried some of the alternatives and I respect the people building them. But I am not satisfied that anything out there is a 1:1 replacement. Matching GitHub’s workflow depth, review tool polish, integration breadth, and the muscle memory millions of developers have built around its interface takes years. No vibe-coded alternative that someone ships this month is going to get there within six months. The product gap is real, and pretending otherwise doesn’t help anyone make good decisions about where to host their and run code.

These are growing pains

I’d actually argue that GitHub’s reliability has held up reasonably well given the meteoric rise in usage as they noted here. The architectural problems they’ve described (tight coupling, insufficient isolation, cascading failures) are exactly what you’d expect in a system that grew this fast. These are growing pains, and the whole industry is going through them right now with agentic development.

That doesn’t excuse the outages ofcourse but it helps contextualizes them.

I’ve worked on database systems where a bad day meant thousands of customers couldn’t perform critical operations. I know what it feels like to be on the other side of an incident that’s trending. The people working on GitHub’s reliability are aware of the problems, already working on them, and already feeling the pressure. Publicly shaming them will not make the Elasticsearch cluster reindex faster.

What I want to happen

What matters more is what they’re doing about it. GitHub has published postmortems, cited specific root causes, and outlined remediation plans but’d like to hear more. The CTO’s availability post is a start, but I want to hear from the people on the ground floor. Engineers who are on-call at 2am when Actions goes down, infrastructure teams rearchitecting the services that cascade, designers who keep the product feeling sharp while the platform is under stress. GitHub is a tool built by developers for developers, and the voices I trust most are the ones doing the building.

Reliability matters, and so does product innovation. GitHub’s shipping cadence over the last few years hasn’t kept up, and I think it can be better. Just look at the competition. GitLab, Linear, Gitpod, and a wave of newer tools are all pushing on workflows that GitHub either ignores or iterates on slowly. Software Development in 2026 is very different from what it was in 2016. Fixing uptime while letting the product stagnate would be trading one problem for another.

Competition is good

GitHub has had effectively no serious competition for years, and pressure from high-profile departures forces a conversation that needed to happen. If projects like Ghostty can move to another provider and thrive, that proves alternatives are viable at scale, and that’s good for everyone.

I want competition in this space. I want GitHub to have to earn its position rather than coast on network effects. But I also want to be honest about where things stand, and right now the alternatives aren’t there for most workflows.

I’m staying

It’s going to take a hundred more outages before I leave. Maybe more. GitHub has earned a long leash from me, partly because of fourteen years of mostly good service, and partly because I don’t see a viable alternative that wouldn’t be a meaningful step down in day-to-day experience.

For now, I’m rooting for the humans behind GitHub to get the product and reliability right.