Like most of you, on August 17th I sat down to review the code that my team had pushed to GitHub. I opened GitHub in a browser to see the Unicorn letting me know there was a problem. Occasionally, we could get it to work for a page or two before we gave up. For a good chunk of that day, my ability to do my job depended on whether one company's load balancers were healthy. Spoiler alert: they weren't.

The incident ran from 13:28 to 21:15 UTC, almost eight hours. At peak, web and API error rates hit about 20%, across Issues, Pull Requests, APIs, Actions, Pages, Webhooks, SAML and OIDC auth, and the Copilot token service all got hit. If your team lives on GitHub, and most of us do, that was a lot of us just thumb-twiddling.

The real problem isn't GitHub, it's that we put everything in one basket

I want to be fair to GitHub before I complain about it. The reason we all ended up here is that GitHub made things easy in a way nobody else did. Free hosting for our repos, setup that took less than two minutes, Actions for CI, and Issues and Projects for planning. Every part of the GitHub experience made it a no-brainer.

So of course the whole web development community jumped on it. We moved all our source control to one vendor, which was nice enough to host the millions of open source packages. Network effects locked it in because if open source lives there, your dependencies resolve there, and every tutorial assumes it. Nobody sat in a meeting and decided "let's make one company able to halt our entire operation." We "sleepwalked" into it, one convenient integration at a time.

The bill for that convenience shows up as a single point of failure. When GitHub is down, it's not just "I can't see my repo." It's I can't do anything because I can't even install my basic dependencies.

Why the outages feel more frequent

The August 17th incident had a root cause worth understanding. According to GitHub's post-mortem, network saturation on the load balancers, driven by a traffic surge plus a misconfigured autoscaling policy that cascaded across their HAProxy nodes, caused the issue. GitHub's own status summary chalked the issue up to high demand.

During the incident, Copilot clients hit authentication retry loops, and those retries amplified load from 7,000 to 9,000 requests per second up to 70,000 to 100,000 per second. AI agents hammering the retry button made the outage worse and dragged it out longer. That's a concrete look at what agentic development is doing to infrastructure that was sized for humans clicking buttons, not swarms of agents pounding the API in a loop.

If it feels like outages come almost weekly now, there are two explanations people argue about. One camp points at Microsoft's stewardship since the 2018 acquisition and watches uptime trends. Community-tracked projects like the GitHub historical uptime tracker exist because enough people wanted to see the pattern for themselves (and it might be my favorite link to send to my leadership team). The other camp points to the rise in agentic development driving spiky, retry-heavy loads that GitHub's architecture wasn't built for.

My honest read is that it's both, and it doesn't change what I need to do. If I'm a team lead trying to ship on a Tuesday, the question of whom to blame is less useful than the question of how to keep working when the site is down. So that's where I've started to put my energy.

Move one: keep a mirror so an outage can't lock you out

One of the best architectural decisions Linus made when creating Git was making it distributed. Every clone is a full copy of the history, so being locked out of a hosted web UI shouldn't stop you from committing, branching, or sharing code, and it won't if you keep a second remote somewhere else.

The simplest version is adding a mirror as a separate remote and pushing to both:

# Add a second remote pointing at a different host
git remote add mirror git@gitlab.com:scott/my-project.git

# Push to it whenever you want a backup
git push mirror main

I've created a Makefile entry to handle keeping my local main in sync with both every time I (or an agent) start a new line of work (make back-to-trunk) so it's almost completely seamless to me.

When GitHub falls over, you still clone, pull, and push against the mirror, and your team keeps moving. It won't run your GitHub Actions or resolve your GitHub-hosted packages, so it's not a full failover, but keeping the code reachable lets me keep working and not lose track of my branches.

Move two: I'm migrating my primary workflow to GitLab

The mirror keeps me alive during an outage. The longer play is not depending on any single host for everything, and for me that means moving toward GitLab, either their hosted version or a self-managed install.

Like GitHub, GitLab bundles the repo, CI, issues, and a container registry into one product, so I'm not stitching five separate GitHub services together and hoping they all stay up as a set. Second, self-managed means I can control the uptime so when my own runner has a bad day, I can look at the logs and fix it instead of refreshing a status page and waiting while I tell my client that I can't fix a bug because a third-party service is down (and good luck trying to explain what a DVCS is to an HR rep).

I won't pretend GitLab is immune. They'll have their own outages, and hosted GitLab can go down the same as anything else. Self-managing trades vendor outages for the joy of being the one on the hook. But at least this way I can do something when it's broken.

What I'd tell a team

The fix here isn't "GitHub bad, switch this weekend." I have a pile of tooling wired into GitHub, and I'm not going to be able to replace it overnight. My goal is to stop letting one vendor be the thing that can stop my entire team cold.

You should start small. Add a mirror remote this week, because it only takes less than an hour and a free account somewhere else. Then have the honest conversation about how much of your critical path runs through a single provider, and decide which pieces you'd want to move first if the outages keep coming. You don't have to completely leave GitHub to stop being "hostage" to it. You just have to make sure that when it's down, your team can still get its work done.

The August 17th outage cost me enough of a workday that I stopped thinking about this and started doing it. I actually wish I'd started a couple of outages ago.