Cursor Origin and the GitHub Outage: Stack Resilience

By Lazar Milicevic · Published October 10, 2026 · 11 min read

Your code lives on GitHub, your CI runs on GitHub Actions, your deploys trigger from GitHub pushes, and your AI coding tools read from GitHub. On August 17, 2026, all of that stopped working at once for most of a workday. This post covers what happened, what Cursor's Origin does and doesn't change, and how to build a dev stack that survives the next incident.

What actually happened on August 17

GitHub's own incident summary puts the outage at 13:28 to 21:15 UTC, which is 7 hours 47 minutes. It hit Issues, Pull Requests, the API, Actions and Copilot. Status updates reported error rates around 20% for web and API traffic, and roughly 50% for archive and raw repository content downloads (GitHub incident thread).

A note on numbers: some outlets reported shorter durations (VentureBeat says six hours and forty-two minutes). I'm using GitHub's own figure. If you quote this elsewhere, check the primary thread first.

Enterprise customers got hit in a second way. SAML and OIDC authentication, SCIM provisioning and Team Sync were affected (ITPro). If your SSO flow sits in front of GitHub, "GitHub is degraded" can turn into "nobody can log in."

The same day, Cursor began rolling out Origin, its own code hosting platform. VentureBeat reports no evidence that Cursor timed the launch to the outage. The coincidence was still too good for people to ignore. Per VentureBeat, Vercel CEO Guillermo Rauch joked that you could host repos in Origin and deploy to Vercel, noting that Origin is itself hosted on Vercel, and admitted Vercel was stuck because of GitHub. Cursor's Matt Palmer quipped that they would have shipped earlier but GitHub was down (VentureBeat).

The jokes are funny. The underlying point is not: a lot of teams discovered they had no plan for "the Git host is down."

Why GitHub went down (and why it matters for your design)

GitHub traced the root cause to network saturation on load balancers in its Central US datacenter. An Istio sidecar hit its concurrency limit, and a misconfigured autoscaling policy was watching the host service instead of the sidecar. Four HAProxy nodes then exhausted their flow limits, which degraded the gateway authentication path (incident thread).

Then it got worse. A latent retry bug in VS Code amplified traffic roughly 10x. Copilot Token Service traffic went from a normal 7-9K requests per second to 70-100K RPS, which delayed Copilot's recovery (incident thread).

GitHub CTO Vlad Fedorov's postmortem, published August 20, described it as a capacity failure rather than a code or configuration change (RuntimeWire). Follow-up actions include fixing the autoscaling policy for sidecar concurrency, auditing Istio limits, reviewing retry limits and backoff, fixing the VS Code retry behavior, and improving load-balancer monitoring and regional failover safeguards (incident thread).

Three design lessons fall out of this, and they apply to your own small stack too:

1. Autoscaling that watches the wrong thing is a silent failure. The metric looked fine while the actual bottleneck was saturated.
2. Retry storms turn a partial outage into a total one. Clients that retry aggressively without backoff make recovery slower for everyone, including themselves.
3. Auth paths are shared fate. When the gateway authentication path degrades, everything behind it looks broken, even services that are technically healthy.

None of these are GitHub-specific. They're the same failure modes you'll meet in your own agents and automations.

It wasn't a one-off

If you're tempted to treat August 17 as a freak event, GitHub's status page suggests otherwise. On October 5, 2026, 14.3% of workflow runs on GitHub-hosted runners did not start within five minutes. On October 7, GitHub had several incidents in a single day affecting Git operations, Pull Requests, Issues and Actions (GitHub Status).

I'm not saying GitHub is unreliable. A platform that size will have incidents, and most of them are small. The point is for planning: assume your Git host will be degraded for some hours several times a year, and decide in advance what your team does when it is.

Be wary of secondary sites quoting big uptime or outage-count statistics. I found several in research that I couldn't trace to an official source, so I'm leaving them out.

What Cursor Origin is, and what it is not

Cursor launched Origin in early beta on August 17, 2026. It rolled out to paid plans (Pro, Teams and Enterprise), except enterprise orgs whose admins opt out, and access opens in stages. It is not on free plans (Cursor changelog, Cursor forum).

What shipped at launch:

• Repos, pull requests, code browsing and GitHub sync
• Integrations with Vercel (a preview deployment for every PR), plus Depot and Buildkite for CI. Both CI providers run existing GitHub Actions workflows, and Buildkite also runs its native pipelines
• A promise that agent-native features would follow later

(Cursor changelog)

What it does not have yet, per a third-party guide: no standalone price (it's included in paid plans), no self-hosting, no public repos, and Issues, Actions workflows and secrets stay on GitHub (Learn Cursor). VentureBeat also reports that Origin's pricing, security architecture, data-handling terms and migration tooling were unpublished at launch (VentureBeat).

Two details matter for resilience planning:

(Cursor changelog)

So a synced repo does not make you resilient to a GitHub outage. Only an Origin-hosted repo takes GitHub out of the path, and that comes with the beta caveats above: no self-hosting, issues and secrets still on GitHub, unpublished terms.

For context, Origin was built by the team from Graphite, a code-review startup Cursor agreed to acquire in December 2025, and was first shown at Cursor's Compile event on June 16, 2026 (Learn Cursor). SpaceX completed its $60 billion all-stock acquisition of Cursor on August 14, 2026, three days before the launch (Tech Startups). I won't speculate about what that ownership means for data handling. The terms weren't published, so I can't tell you, and neither can anyone quoting performance numbers from the June demo, which weren't independently verified.

My read: Origin is interesting, and an AI-native Git host is a plausible direction. But a beta with unpublished security and data terms is not where I'd move a client's production code on day one. Evaluate it on a non-critical repo.

Map your single points of failure

Before choosing tools, find out what actually breaks when your Git host disappears. Here's the audit I'd run on any small team's stack. Fill it in honestly:

For most solo developers and small teams, the answer to nearly every row is "it all lives in one place." That's convenient until it isn't.

Practical redundancy that costs almost nothing

You don't need to migrate platforms to survive an eight-hour outage. You need a few cheap habits.

1. Keep a second remote that is always current

Git is distributed. Use that. Push to a second host on every push to the first. A mirror on any other provider works; the provider is your choice.

# Add a mirror remote once
git remote add mirror git@your-second-host.example:org/repo.git

# Push all branches and tags to both
git push origin --all && git push mirror --all
git push origin --tags && git push mirror --tags

To automate it, a scheduled job on a cheap server or your own machine can keep the mirror fresh:

#!/usr/bin/env bash
# mirror-sync.sh - run from cron every 15 minutes
set -euo pipefail

REPO_DIR="$HOME/mirrors/myrepo.git"

if [ ! -d "$REPO_DIR" ]; then
  git clone --mirror git@primary-host.example:org/repo.git "$REPO_DIR"
fi

cd "$REPO_DIR"
git remote update --prune
git push --mirror git@your-second-host.example:org/repo.git

Mirroring only covers code, not issues, PR comments or secrets. That's a limit worth knowing about, and it's why the next two items matter.

2. Make CI portable

If your whole build is a pile of host-specific workflow YAML that only runs on one platform's runners, you can't build during an outage. Put the real logic in scripts you can run anywhere, and let the workflow file be a thin wrapper.

#!/usr/bin/env bash
# ci/build.sh - the real build. The CI config just calls this.
set -euo pipefail

npm ci
npm run lint
npm test
npm run build

# .github/workflows/ci.yml - thin wrapper only
name: ci
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./ci/build.sh

Now ./ci/build.sh runs on your laptop, a spare VPS, or a different CI provider. For a hotfix during an outage, that is the difference between shipping and waiting.

3. Keep an emergency deploy path

Write down, and test once, a manual deploy that doesn't depend on the Git host's pipeline. It can be an ugly script. It only has to work.

#!/usr/bin/env bash
# emergency-deploy.sh - tested manually, used only when CI is down
set -euo pipefail

./ci/build.sh
rsync -az --delete ./dist/ deploy@your-server.example:/var/www/app/
ssh deploy@your-server.example 'sudo systemctl reload app'

Test it once a quarter. An untested emergency script is a story you tell yourself.

4. Back up the non-code state

Issues, PR discussions and wikis don't live in a Git mirror. Export them periodically through the platform's API into a plain archive. Even a weekly JSON dump beats nothing when you need to remember why a decision was made.

5. Don't make auth a single thread

If your SSO provider and your Git host are tangled together, an auth-path problem locks you out of both. Keep at least one break-glass account with a non-SSO login on your critical tools, stored securely and tested.

Designing AI coding workflows that tolerate a down host

AI coding agents add a new wrinkle: many of them pull context and open PRs through the Git host's API. When the API runs at roughly 20% errors, an agent that retries without backoff makes things worse, the same pattern that amplified the VS Code traffic on August 17.

I haven't found any source showing how the outage affected specific Cursor or Claude Code users, so what follows is my engineering opinion, not a reported finding. These are the principles I apply:

• Agents should work from a local checkout, not live API calls. If the agent can read the working tree, a hosting outage doesn't blind it.
• Cap retries and add backoff. An agent loop should fail fast and loudly after a few attempts, then stop. Never let it hammer a degraded API.
• Separate "write code" from "publish code." The agent can commit locally for hours. Publishing the PR is a queued step that waits for the host to recover.
• Keep project context in the repo. Instructions, conventions and tool configs belong in files your agent reads locally, not in a web UI that goes down with the platform.
• Use more than one tool surface. If one editor-based agent is down or degraded, you should be able to continue with another, such as a terminal-based one, against the same local repo.

A simple publish queue makes the second and third points concrete:

import subprocess
import time

MAX_ATTEMPTS = 4
BASE_DELAY_SECONDS = 5

def publish_branch(branch: str) -> bool:
    """Push with capped retries and exponential backoff. Fail loudly."""
    for attempt in range(MAX_ATTEMPTS):
        result = subprocess.run(
            ["git", "push", "origin", branch],
            capture_output=True, text=True,
        )
        if result.returncode == 0:
            return True
        delay = BASE_DELAY_SECONDS * (2 ** attempt)
        print(f"push failed (attempt {attempt + 1}/{MAX_ATTEMPTS}), "
              f"retrying in {delay}s: {result.stderr.strip()[:200]}")
        time.sleep(delay)
    print(f"giving up on {branch}; leaving it queued locally")
    return False

It's not clever. The goal is that when the host is down, your tooling degrades politely and your work stays safe on disk.

Should you move to Origin, a competitor, or stay put?

Here's the decision framework I'd use, with no assumptions about what you pick.

Stay on GitHub, add redundancy if you have an established team, Actions workflows, integrations and secrets that are expensive to move. A mirror plus portable CI buys most of the resilience for a modest amount of setup. This is the right default for most small businesses.

Trial Origin on a non-critical repo if you already pay for a Cursor plan and want an AI-native review and hosting experience. Remember it's an early beta: no self-hosting, no public repos, issues and secrets still on GitHub, and pricing and data terms weren't published at launch (Learn Cursor). Treat the trial as research, and read the terms before putting anything sensitive on it.

Don't treat Origin as your redundancy plan yet. In sync mode GitHub remains the source of truth, so a GitHub outage still touches you. In Origin-hosted mode you're trading one single vendor for another, and a younger one.

The honest summary: Origin shows the market is moving, and the August 17 outage showed why people care. But your resilience comes from your architecture, not from picking the vendor that happened to be up that Monday.

Planning for the day a vendor is down

Lazar builds AI automations and plans for the case where a vendor goes down. In practice that means keeping agent instructions and project context in the repo rather than in a hosted UI, putting build logic in portable scripts so CI can run elsewhere, maintaining a mirrored remote and a tested emergency deploy path, and capping retries in agent loops so a degraded API doesn't turn into a retry storm.

None of that is exotic. In my experience it's a modest amount of setup, and the August 17 outage was a good reminder that "it's always been fine" isn't a plan. If you want to audit your own dev stack for single points of failure, work through the table above layer by layer and write down what you'd do for each row on the next bad day.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.