Cursor Origin Landed During a GitHub Outage

GitHub spent 7 hours and 47 minutes inside a critical incident on August 17, 2026, and Cursor Origin went live the same morning. On X the coincidence read as a stunt, and a fair number of people said so out loud. The launch had been trailed publicly beforehand, though; TestingCatalog reported Cursor was preparing a code-review platform under that name before anything broke. What the collision actually did was put one question in front of a lot of developers on the same afternoon, which is whether keeping every repository, every CI trigger and every code review inside a single provider is still a sensible default.

This is what shipped, what the outage actually was, and which parts of the problem a new git host does not touch.

Key Takeaways:

• GitHub's August 17 incident ran 13:28-21:15 UTC, 7 hours 47 minutes, with peak error rates near 20% on web and API and about 50% on archive and raw-content downloads.
• Counted from GitHub's status API on August 19: 15 incidents in 17 days, 32 in 30 days, including 5 critical and 7 major.
• Cursor Origin launched the same morning as a git forge aimed at agent workflows. It's early beta, and code storage requires a Pro, Teams or Enterprise plan.
• Mirroring keeps GitHub as the source of truth, so Origin is not an outage hedge for repos that started life on GitHub.
• Where code is hosted and where an agent runs are separate problems; solving one leaves the other exactly where it was.

What broke on August 17

GitHub's own incident report is unusually specific, so there's no need to guess. Between 13:28 and 21:15 UTC, error rates on the web and API sat around 20% at peak, while archive and raw-content downloads reached roughly 50%. Issues, Pull Requests, Actions, Copilot, Git Operations, Pages and Webhooks all went degraded. SAML/OIDC authentication, SCIM and Team Sync were caught in it too, which is the part that turns a bad afternoon into a company-wide one.

The root cause is worth reading if you run Kubernetes. An Istio sidecar pod hit its concurrency limits and failed to scale, because the autoscaling policy watched the host service rather than the sidecar. One failure cascaded until four HAProxy nodes exhausted their flow limits, which degraded the gateway auth path. Retry logic then made it worse: a latent bug in VS Code amplified traffic by about 10x, and Copilot Token Service load went from a normal 7,000-9,000 requests per second to somewhere between 70,000 and 100,000. GitHub also notes that scraping attacks on codeload endpoints slowed the recovery down.

Users described it more bluntly than any status page would. "Commits are not showing up, and the pull page is crashing," one person wrote on Reddit that morning. Another: "Was not able to suddenly raise a PR and then copilot stopped responding too."

What Cursor Origin actually is

Cursor calls Origin "a git forge for the agentic era," which is marketing language for a code host designed around agents opening and merging pull requests rather than humans clicking buttons. The practical description in the docs is plainer: create repos, push and pull with standard git, mirror from GitHub, browse and search code, open and merge pull requests, share with your Cursor team.

A few specifics matter more than the positioning, all accurate as of 2026-08-19. Origin is in early beta. Code storage runs on Pro, Teams and Enterprise plans and is not available on free plans, so this is not something you try on a whim. Your team claims a namespace at cursor.com/codebase, and during the beta you can't change that namespace once it's taken, which is a small decision that becomes permanent faster than most beta decisions do. Privacy follows the Privacy Mode of whoever owns the namespace.

The remote looks like any other git remote. Cursor's docs show git remote add origin https://origin.cursor.com/git/user-ops-test-team/hello-origin, and everything after that is ordinary git.

The part the launch coverage skipped

Origin is not a GitHub exit, and Cursor doesn't claim it is. When you mirror a GitHub repository, pushes keep going to GitHub, and GitHub stays the source of truth for anything that started there. Pull request conversations sync in both directions. That's a genuinely reasonable design for a beta, and it's also the reason Origin would not have saved you on August 17: if GitHub is the source of truth for your mirrored repo and GitHub is returning errors on one request in five, a second interface onto the same data doesn't give you a working system.

There's a sharper version of this that a developer posted after the previous outage on August 6, and it applies to every "just self-host it" reply in every outage thread: the self-hosted runners went down too, because you can own the hardware and still eat the outage when the provider owns the orchestration and the triggers. Owning the box is not the same as owning the control plane. Moving your repos to a different forge relocates the dependency; it doesn't remove it, and for the first while it gives you two dependencies instead of one. We've written before about what self-hosting an agent actually costs you, and the arithmetic here is the same shape: the bill for independence is paid in operations, not in licence fees.

The number that isn't on any status page

Single outages are easy to shrug off. The pattern is the harder thing to argue with, and GitHub publishes the raw material for it: every incident, with timestamps and severity, through the status API.

Counting from that feed on the morning of August 19, GitHub logged 15 incidents in the previous 17 days. Widen it to 30 days and the count is 32, of which 5 were rated critical and 7 major. That's the number that changes the conversation, because a 7-hour outage is an accident while a two-a-day incident rate is a capacity story. The Register has been making roughly this argument since June, tying the pattern to AI-driven traffic growth, and GitHub's own August 17 write-up points the same direction when it blames "a new peak in traffic."

None of that means GitHub is careless. Running the world's default code host through the period when every developer suddenly attached an agent to it is genuinely hard, and the follow-up actions in the report are the right ones. But if your build, your reviews and your agents all terminate at the same hostname, the incident rate is now a number to plan around rather than ignore.

Where your agent runs is a different question

Here's the distinction that got lost in the launch noise. Cursor Origin changes where your code lives. It does not change where your agent runs, and on August 17 those failed in different ways for different reasons.

Consider what actually stopped that afternoon. Pushes failed, but Copilot also stopped responding, because the Copilot Token Service was drowning in retries from clients that wouldn't back off, and those clients were editors on people's laptops. An agent tied to your local editor session inherits every failure of that session: its network, its machine, whether that machine is awake. Close the lid and the work stops, a constraint with nothing to do with git hosting.

That gap is the one MoClaw fills, and it's a narrower claim than "GitHub alternative." It's a hosted cloud AI computer, so the agent's runtime is a machine that stays up rather than a laptop asleep on a train, and a long job keeps going through the hours you spend not looking at it.

It also sits alongside your existing setup rather than replacing it. Nobody sensible migrates 400 repositories off GitHub because of a bad Monday, and MoClaw doesn't ask you to: repos stay where they are, editor stays where it is. What changes is that one long-running job isn't pinned to one physical device — pick it up from another machine later and it's still running.

That also means MoClaw is not a hedge against GitHub going down, and pretending otherwise would be selling you something. If your pipeline needs to clone from GitHub and GitHub is returning 500s, a hosted computer clones nothing. What it removes is a smaller and more common failure: the one where the work was fine and your laptop wasn't. The always-on agent pattern is the same idea from the other direction.

What's worth doing this week

Very little, honestly, and that's the correct answer for a two-day-old beta. Claiming your team's namespace on Origin costs nothing if you're already on a paid Cursor plan, and since the namespace is permanent during the beta, claiming it early is the one time-sensitive item on the list.

Beyond that, the useful work is unglamorous. Find out which pipelines fail closed when GitHub returns errors and which retry forever, because the August 17 report is largely a story about retry logic making an outage worse. Check whether your agents hold credentials that expire mid-outage, which is what turned a degraded auth path into hours of Copilot failures. If you keep a mirror, keep it somewhere you can actually read from. None of that requires picking a side in the agent tooling comparison everyone is having.

FAQ

Is Cursor Origin free?

No. As of 2026-08-19, Origin code storage runs on Cursor's Pro, Teams and Enterprise plans, and the documentation states it is not available on free plans. The early beta is described as available on all paid plans.

Does Cursor Origin replace GitHub?

Not in its current form. You can create repos that live only in Origin, but for mirrored repositories Cursor's documentation says pushes keep going to GitHub and GitHub remains the source of truth, with pull request conversations syncing both ways.

Would Cursor Origin have helped during the August 17 GitHub outage?

For a mirrored repo, no, because the authoritative copy was still the one having problems. A repository created directly in Origin sits on different infrastructure, though it was hours old at that point and had no track record behind it.

How often does GitHub actually go down?

Reading GitHub's own status feed on August 19, 2026: 15 incidents in the previous 17 days and 32 in the previous 30, with 5 rated critical and 7 major. Most were minor and short. The severity mix matters more than the raw count.

What caused the August 17 outage?

GitHub's report points to network saturation on load balancers in Central US, starting with an Istio sidecar pod that hit its concurrency limits and failed to autoscale because the scaling policy watched the host service rather than the sidecar. Four HAProxy nodes then exhausted their flow limits, and aggressive client retries, including a VS Code bug that amplified traffic roughly 10x, extended the recovery.

Can I move an existing repo into Cursor Origin?

Yes, the beta supports mirroring a GitHub repository into Origin, plus clone, push and pull with standard git against an origin.cursor.com remote. Note that the namespace your team claims cannot be changed during the beta.