A founding GitHub user and HashiCorp co-founder has publicly quit the platform after tracking a dismal 90.21 percent uptime over a month, marking a sharp escalation in the service’s ongoing reliability woes. Mitchell Hashimoto, creator of the Ghostty terminal emulator, announced on April 28 that he could no longer treat GitHub as a place for serious work, citing near-daily disruptions that blocked pull request reviews, CI workflows, and code pushes. His exit comes as Microsoft folds GitHub deeper into its AI division and users from open-source projects to enterprise teams report mounting frustration with degraded performance.
What’s Actually Breaking
GitHub’s reliability troubles are not a single crash but a cascade of partial failures that have hit critical developer workflows over the past several months. The company’s own availability reports, published more transparently after recent criticism, detail repeated incidents affecting Git operations, the API, Actions, Codespaces, search indexing, and Dependabot. In isolation, each might be an edge case; together they paint a picture of a platform struggling under its own weight.
The most alarming incident involved a merge queue bug in early April. According to GitHub’s remediation post, misconfigured squash merges produced incorrect merge commits in certain conditions, impacting hundreds of repositories and thousands of pull requests. While no data was permanently lost, the integrity of branches—the bedrock of any version-control system—was compromised. For developers who depend on a precise audit trail, that’s a glaring red flag.
Other common complaints include sluggish pull request pages that fail to load diffs, Actions runner queues stalling for hours, webhook deliveries timing out, and search returning empty results even when indexed. These are not edge-case errors; they hit the very workflows that make GitHub an indispensable development hub. Hashimoto’s personal journal, which marked an ‘X’ on every day a GitHub outage blocked his work, revealed that on some days he couldn’t review PRs for over two hours due to an Actions outage. “This is no longer a place for serious work,” he wrote.
The company attributes much of the strain to a surge in AI-driven traffic. Since late 2025, GitHub has observed a sharp increase in repository creation, API calls, pull requests, and automation—much of it from coding agents that behave like bots, hammering systems at machine speed. A single AI agent can open dozens of PRs, trigger CI, and poll APIs far more aggressively than a human developer, exposing bottlenecks in cache layers, load balancers, and datastore connections that were never designed for such load profiles.
What This Means for You
The impact of GitHub’s instability depends heavily on how you use the platform. Here’s a breakdown by audience.
For Individual Developers and Hobbyists
If you’re a solo developer or part of a small team, you’ve likely noticed the friction: a push that takes minutes to appear, a PR diff that spins forever, or a CI job that queues for an hour before starting. These delays break your flow and eat into productive time. Worse, when Actions are down, you lose automated testing and deployment, which may force risky manual workarounds. The emotional toll is real—many users report exhaustion from constantly refreshing status pages and debating whether to retry a failing workflow.
For Open-Source Maintainers
Open-source maintainers like Hashimoto are perhaps the most exposed. They manage high-volume repos with external contributors, complex CI matrices, and a heavy reliance on GitHub’s social layer (issues, PRs, discussions). When GitHub stutters, maintainers cannot triage bugs, merge patches, or communicate with their community. The Zig programming language’s migration to Codeberg in late 2025 cited similar frustrations: sluggish UI, broken Actions, and an engineering culture that prioritizes AI features over core reliability. If other prominent projects follow Ghostty and Zig, the network effects that keep open source locked into GitHub could start to unravel.
For Enterprise Teams and IT Admins
Enterprises facing GitHub outages risk more than individual productivity—they risk delayed releases, blocked security patches, and broken compliance pipelines. A stalled Actions queue can prevent a critical hotfix from reaching production; a degraded API can disrupt internal tooling that depends on webhooks or repository metadata. Many large organizations have built their entire developer platform around GitHub, stitching it together with identity providers, ticketing systems, and deployment gates. When GitHub breaks, the blast radius extends far beyond the code repository.
Service-level agreements (SLAs) may offer credits, but credits don’t ship software. The hidden costs lie in the workarounds teams adopt: skipping code review, bypassing automated tests, or merging without proper checks. These shortcuts introduce technical debt and security risks. Admins should start evaluating fallback strategies now—mirroring critical repos on alternative forges, setting up self-hosted runners for CI, and ensuring compliance workflows can tolerate temporary GitHub unavailability.
How We Got Here
Microsoft acquired GitHub in 2018 for $7.5 billion, promising to preserve its developer-first ethos while adding enterprise muscle. For years, that promise held: GitHub Actions emerged as a powerful CI/CD platform, Copilot became an AI sensation, and the service continued to grow. But under the surface, the platform’s complexity was ballooning. What started as a Git host now encompasses packages, security scanning, project management, Codespaces, and an AI coding assistant that can generate code, reviews, and entire workflows.
This expansion multiplied failure points. Each new feature tied into existing subsystems—search, Git storage, authentication, CI runners—creating hidden coupling. GitHub’s post-incident analyses repeatedly point to cascading failures: a Redis glitch snowballs into an API outage; a load balancer misconfiguration takes down merge queues. The platform’s architecture, fine-tuned for human-paced development, was not hardened against the relentless, high-volume traffic of AI agents.
Organizational shifts within Microsoft have also raised eyebrows. In 2025, GitHub was moved under the CoreAI division, signaling that its strategic value now centers on AI monetization rather than independent developer services. Longtime CEO Thomas Dohmke departed, and the new reporting structure blends GitHub’s roadmap more tightly with Copilot and Azure AI. While the operational teams may still be dedicated to reliability, the public perception is that AI flash wins internal battles while boring infrastructure work loses.
This perception is amplified by a broader Microsoft pattern that users have called out in Windows and Xbox: core quality feels secondary to AI-driven features, subscriptions, and ads. For GitHub, the result is a trust gap—developers see an AI dashboard every time they log in, but they can’t land a pull request without refreshing the page three times.
What to Do Now
If you’re feeling the pain, here are concrete steps to protect your work and push for change.
1. Monitor Beyond the Status Page
GitHub’s public status page often lags behind user-perceived issues. Use community-driven trackers like GitHubStatus.com (unofficial) or follow the hashtag #githubdown on social media. For enterprise teams, set up internal monitors that probe your most critical API endpoints and Actions workflows so you know about failures before your developers do.
2. Design for Degradability
Assume GitHub will sometimes be half-broken. Where possible, decouple your critical pipelines: store essential artifacts in a separate location (Azure Blob Storage, S3), set up self-hosted Actions runners that can operate even if GitHub’s shared runners are down, and mirror repositories to a secondary forge like GitLab, Codeberg, or a self-hosted Gitea instance. Even a simple read-only mirror can save you during a disruption.
3. Evaluate Alternatives for Sensitive Workloads
For open-source projects, consider moving canonical development to a platform that aligns with your governance values. Codeberg and Forgejo offer nonprofit-backed hosting with fewer AI-driven distractions. For enterprises, GitLab’s integrated DevSecOps suite provides a mature alternative with strong self-managed options. You don’t have to leave GitHub entirely—many projects keep a mirror there for visibility while doing primary work elsewhere.
4. Pressure GitHub with Your Feedback—and Your Wallet
GitHub’s CCO Kyle Daigle personally apologized to Hashimoto and pledged “real proof, not words.” That only happens when high-profile users speak out. If you maintain a popular project or manage a corporate account, contact GitHub support and your account manager to document every incident. Be specific: timestamp, affected workflow, business impact. When contract renewal comes up, use that data to demand reliability commitments.
5. Stay Alert for Rapid Changes
GitHub has acknowledged the need for better capacity, isolation, and incident communication. Watch for concrete milestones: a dedicated status page that shows per-workflow health, separate infrastructure for critical Git and Actions paths, and public roadmaps that prioritize stability over AI features. If these don’t materialize, it’s a signal that the platform’s priorities remain elsewhere.
Outlook
The next few months will be crucial. If GitHub can string together several weeks of quiet, stable service—especially around Actions, pull requests, and Git operations—some trust may be restored. But the damage to its reputation among cornerstone open-source maintainers could have a long tail, as more projects publicly weigh alternatives. Microsoft’s challenge is to prove that its AI ambitions can coexist with, rather than cannibalize, the reliability that made GitHub the home of software development. Developers are watching both the status page and the org chart.