# Why Your Company's Entire Engineering History Could Disappear Overnight

_Published: 2026-08-18_

If you or your company depends on GitHub, today was a pretty good reminder of how much of the modern software industry now depends on a single platform.

GitHub had a major outage affecting developers around the world, almost at the same time that Cursor entered the code-hosting market with Origin. It naturally raises two questions: should companies be looking at alternatives to GitHub, and how much should they depend on a single Git host? One outage doesn't mean everyone should move away from GitHub, but given how often GitHub has had outages recently, it's a good moment to start thinking seriously about alternatives and backups for when your primary host goes down.

I actually believe GitHub should still be the first choice for most companies. It has the largest developer ecosystem, an enormous number of integrations, a mature offering, and years of infra behind it. For most people and teams, there's a very good reason why GitHub is the default.

GitHub is no longer simply a place where your Git repository lives. For many companies, projects, and people, it's woven into CI/CD pipelines, deployments via Actions, package distribution, authentication, issue tracking, discussions, docs, and a growing list of other workflows. Your dependence on GitHub is only likely to increase. There are two reasons you shouldn't depend on GitHub alone:

### **1. AI Agents Will Put More Pressure on GitHub**

A developer might create a handful of branches, commits and pull requests in a day. An agent can potentially create and interact with them at a much higher rate. As AI coding becomes more common, GitHub will have to handle far more automated code generation, PRs, reviews and CI workloads, putting even more pressure on its infrastructure.

### **2. GitHub's Direction Is Becoming Harder to Ignore**

Despite having some of the best engineers in the industry, there are growing questions around GitHub's direction. Since Microsoft's acquisition, there have been periods of leadership uncertainty, including time without a permanent CEO, and at times the platform has lacked a clear sense of direction. As GitHub becomes even more critical to software development, that uncertainty is harder to ignore.

That's also why I think the conversation around alternatives is becoming more interesting.

GitLab and other Git hosting platforms have been around for years, and now we're seeing new entrants like Cursor with Origin trying to approach code hosting from a more AI-native perspective. Whether Origin becomes a serious competitor to GitHub is impossible to know right now, but I think competition in this space is healthy.

Migrating a large engineering organisation is not a small decision, and GitHub's ecosystem is a huge part of its value. The point isn't that GitHub is suddenly a bad choice. The point is that being the best or **most popular platform doesn't mean it should also be the only place your company's development history exists.**

**Your Git repository is one of the most important assets your company has. **It can contain years of source code, commits, branches, tags, pull requests, configuration and development history.

**If GitHub is your primary Git host, I don't think you need to move away from it. But I also wouldn't keep the only copy of your code there. At the very least, mirror your repositories somewhere else or keep regular backups in S3 or another storage provider. **So, if GitHub goes down, you still have access to your code and can keep working.

**The exact implementation isn't particularly important. **What matters is having a backup and recovery strategy that doesn't depend entirely on the same service that just went down.

There is also an important distinction between reliability and disaster recovery. I trust GitHub to be reliable. Millions of developers use it every day, and the company has had years to build infrastructure at enormous scale. But reliability doesn't mean a service will never have an incident, and it certainly doesn't mean your company shouldn't have a backup plan.

That's really the takeaway I would have from today.

I would still pick GitHub for a new project. I would still expect most companies to continue using it. But I wouldn't confuse using GitHub with not having a backup.

The interesting thing to watch now is what happens as Git hosting becomes even more central to AI-assisted development. When agents are creating branches, opening pull requests, running tests, and interacting with repositories at a much higher volume than individual developers, these platforms are going to become even more important.

What I do think is that companies should have a clear answer to a much simpler question:

**If our Git provider is unavailable tomorrow, can we recover, and do we have a backup and a recovery plan?**

That question is probably more important than which Git provider you currently use and worth including in your system design brainstroming.