On August 17, GitHub went down again. The same day, Cursor launched Origin, its own Git hosting platform, into the outage. Guillermo Rauch, whose company hosts it, posted the obvious line: "You can now host your repos in Cursor Origin and deploy to Vercel via Cursor Origin which is itself hosted on Vercel. And unlike GitHub, it's online."
Then Cursor's status page published an incident titled "GitHub degradation affects Cursor Origin." The GitHub alternative, launched during a GitHub outage, was degraded by the GitHub outage. Hacker News found it within the hour: "So they announce this to try and take people away from GitHub, but it also depended on GitHub? Am I reading this irony correctly?"
Yes. And the reason it happened is the reason this matters past the dunk.
Why your git host is now production infrastructure
For twenty years an outage at your code host was an inconvenience with a workaround. You had a full copy of the repository on your laptop, because that is what distributed version control means. You kept working and pushed later.
That stops being true the moment your work continues without you. Grok Bot runs on a machine you do not own, and the whole selling point is that closing your laptop changes nothing. So when the host goes down at 3am, the local copy that used to save you is on a laptop that is asleep, and the fleet that is awake cannot clone, cannot push, and cannot open a pull request. An outage that used to cost you an afternoon now costs you a shift you were not watching.
Multiply that by agents that commit far more often than people do, and the load profile changes too. This is not a small increase in traffic. It is a different customer.
Three parties moved into the same gap
GitHub's problem is not new and not secret. Gergely Orosz, who has tracked platform reliability for years, was blunt about it on the day of the outage.
Orosz
"Incredible how GitHub's eng team knows reliability (having zero nines) is their #1 problem for ~6 months now and seemingly not being able to get a handle on it. Despite so many solid engineers working on it. My bet: arch decisions years ago bite back v hard now."
Three responses to that gap are now live at once, and the second one is the tell.
Cursor Origin. Git hosting built into the IDE, with Vercel, Buildkite and Depot integrations at launch. Cursor's engineering write-up, "Git at any scale," explains the architecture honestly: Git's packfile format is "the fundamental building block of Git storage and Git networking," and it is a poor fit for serving repositories at scale, so they rebuilt their storage layer to behave like a database instead. Twenty years of accumulated design debt, described by the people trying to route around it.
EntireHQ. Built by GitHub's own former CEO, and described by Orosz as "a service designed to take the agentic load GitHub cannot." He put money in, noting it was his only investment in three years. When the person who ran the incumbent builds the replacement and frames it around agent traffic specifically, that is a stronger signal than any competitor's launch post.
The rest of the field. GitLab and Zed are pushing their own answers. The framing that circulated in June still holds: everyone agrees GitHub is breaking, and they disagree about how to rebuild it.
What Origin is not, yet
Be careful here, because the launch enthusiasm outran the product. Origin's own developer, asked on Hacker News what differentiates it from GitHub today, answered: "Today, very little. We're intentionally releasing this as a Github alternative where we meet them toe-to-toe on functionality." That is a refreshingly straight answer and it is also the whole caveat.
Three more things to weigh. Origin's onboarding is "sync your repos from GitHub," which is precisely why a GitHub outage degraded it on day one, so it is not yet an independent failure domain. It is available on paid Cursor plans and not on free ones. And it means your source code now sits with SpaceXAI, which is a governance question for some companies and a dealbreaker for others, on top of the credential questions the agent platforms already raise.
What to actually do
Decide whether your agents are allowed to be blocked. If a bot fleet works overnight, write down what happens when the host is unavailable at 3am. If the answer is "the work silently does not happen," that is a decision you have made by accident.
Keep a copy you control. The oldest answer is still the best one: a mirror you own, pushed on a schedule. Git was designed for exactly this and the industry stopped using the feature because the host was reliable enough. It is not, currently.
Do not confuse a second vendor with a second failure domain. An alternative that syncs from the incumbent inherits the incumbent's outages until you cut the cord. Cursor's own status page proved that on launch day.
Judge Origin in six months, not this week. Its differentiation today is honestly stated as very little. The architecture argument is real, the reliability claim is unproven, and one good week during a competitor's bad week is not evidence.
GitHub's outages were an annoyance for as long as the people doing the committing were awake to route around them. That assumption is what agents removed, and it is why a boring infrastructure question ended up inside a guide about bots.
Mirror what matters.
What breaks when your agents cannot push?
Book a free Diagnostic: 30 to 45 minutes, no deck, no pitch. We map which of your automated work depends on a single provider being up, and what a mirror you control would actually cost you to run.
Book the Diagnostic →